On 17.09.2019 19:17, Andrew Cooper wrote:
> On 16/09/2019 10:48, Jan Beulich wrote:
>> XED commit 1b2fd94425 ("Update MOVSXD to modern behavior") points out
>> that as of SDM rev 064 MOVSXD is specified to read only 16 bits from
>> memory (or register) when used without REX.W and with operand size
flight 141384 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141384/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 141356
test-armhf-armhf-libvirt-raw 13 saveresto
On 16.09.19 11:44, Jan Beulich wrote:
I've noticed the issue the 1st patch means to address only while
putting together the 2nd. Considering the other Hygon enablement
in this release cycle I think we want patch 1 for 4.13. Patch 2
should be considered too, but we've been effectively mis-emulatin
flight 141409 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141409/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
flight 141380 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141380/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 18be724e302295164f00c955b6c407991f57b172
baseline version:
ovmf 9b5a1c789d396683e56e8
flight 141405 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141405/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
flight 141372 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141372/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
129313
build-armhf-
On 17/09/2019 07:17, Jan Beulich wrote:
> This allows in particular some streamlining of the TLB flushing code
> paths.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenp
On 17/09/2019 07:17, Jan Beulich wrote:
> PCID validly depends on LM, as it can be enabled in Long Mode only.
> INVPCID, otoh, can be used not only without PCID enabled, but also
> outside of Long Mode altogether. In both cases its functionality is
> simply restricted to PCID 0, which is sort of ex
On 17/09/2019 07:16, Jan Beulich wrote:
> Eliminate the not really useful local variable "old". Reduce the scope
> of "page". Rename the latched "current".
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Roger Pau Monné
Acked-by: Andrew Cooper
___
Xen-
On 17/09/2019 07:16, Jan Beulich wrote:
> There's no need to re-obtain a page reference if only bits not affecting
> the address change.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Roger Pau Monné
Acked-by: Andrew Cooper
___
Xen-devel mailing list
On 17/09/2019 07:15, Jan Beulich wrote:
> While bits 11 and below are, if not used for other purposes, reserved
> but ignored, bits beyond physical address width are supposed to raise
> exceptions (at least in the non-nested case; I'm not convinced the
> current nested SVM/VMX behavior of raising #
On 17/09/2019 07:15, Jan Beulich wrote:
> The bit is meaningful only for MOV-to-CR3 insns, not anywhere else, in
> particular not when loading nested guest state.
I've found a footnote for "26.3.1.1 Checks on Guest Control Registers,
Debug Registers, and MSRs" stating:
"Bit 63 of the CR3 field in
flight 141397 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141397/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
On 17/09/2019 07:14, Jan Beulich wrote:
> I can't see any technical or performance reason why we should treat
> 32-bit PV different from 64-bit PV in this regard.
Well, other than the fact this setting is only read for a 64bit guest...
The reason it isn't set for 32bit guests is that there is no
On 17/09/2019 07:13, Jan Beulich wrote:
> We really need to flush the TLB just once, if we do so with or after the
> CR3 write. The only case where two flushes are unavoidable is when we
> mean to turn off CR4.PGE (perhaps just temporarily; see the code
> comment).
>
> Signed-off-by: Jan Beulich
>
Hi,
On 9/17/19 1:28 PM, Volodymyr Babchuk wrote:
Hi Julien,
Julien Grall writes:
Hi Volodymyr,
On 9/16/19 4:26 PM, Volodymyr Babchuk wrote:
Hi Julien,
Julien Grall writes:
Hi,
On 9/12/19 8:45 PM, Volodymyr Babchuk wrote:
Hi Julien,
Julien Grall writes:
Hi Volodymyr,
On 9/11/19
Andrew Cooper writes ("[PATCH] tools/libs: Fix build following c/s 56dccee3f,
take 2"):
> The fix for c/s 01ba8f62b618 was speculative given no local repro. It turns
> out that it didn't fix the problem.
>
> The $(AUTOINCS) variable needs to be visible before libs.mk is included, to
> have any e
On 02/09/2019 11:46, Jan Beulich wrote:
> On 02.09.2019 12:37, Andrew Cooper wrote:
>> On 30/08/2019 14:33, Jan Beulich wrote:
>>> When disabling SMT at runtime, secondary threads should no longer be
>>> candidates for bringing back up in response to _PUD ACPI events. Purge
>>> them from the tracki
The fix for c/s 01ba8f62b618 was speculative given no local repro. It turns
out that it didn't fix the problem.
The $(AUTOINCS) variable needs to be visible before libs.mk is included, to
have any effect.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Juergen Gross
---
too
On 17.09.19 09:12, Jan Beulich wrote:
Hi, Jan
On 16.09.2019 20:08, Oleksandr wrote:
On 16.09.19 13:40, Jan Beulich wrote:
+/* per-device IOMMU instance data */
+struct iommu_fwspec {
+/* this device's IOMMU */
+struct device *iommu_dev;
+/* IOMMU driver private data for this devi
At the moment, the fixmap table is only hooked when earlyprintk is used.
This is fine today because in C land, the fixmap is not used by anyone
until the the boot CPU is switching to the runtime page-tables.
In the future, the boot CPU will not switch between page-tables to
avoid TLB incoherency.
The 1:1 mapping may clash with other parts of the Xen virtual memory
layout. At the moment, Xen is handling the clash by only creating a
mapping to the runtime virtual address before enabling the MMU.
The rest of the mappings (such as the fixmap) will be mapped after the
MMU is enabled. However, t
At the moment, any update to the boot-pages are open-coded. This is
making more difficult to understand the logic of a function as each
update roughly requires 6 instructions.
To ease the readability, two new macros are introduced:
- create_table_entry: Create a page-table entry in a given tab
At the moment, any update to the boot-pages are open-coded. This is
making more difficult to understand the logic of a function as each
update roughly requires 6 instructions.
To ease the readability, two new macros are introduced:
- create_table_entry: Create a page-table entry in a given tab
At the moment the function create_page_tables() will use 1GB/2MB
mapping for the identity mapping. As we don't know what is present
before and after Xen in memory, we may end up to map
device/reserved-memory with cacheable memory. This may result to
mismatched attributes as other users may access t
At the moment the function create_page_tables() will use 1GB/2MB
mapping for the identity mapping. As we don't know what is present
before and after Xen in memory, we may end up to map
device/reserved-memory with cacheable memory. This may result to
mismatched attributes as other users may access t
Hi all,
This is part of the boot/memory rework for Xen on Arm, but not sent as
MM-PARTx as this is focusing on the boot code.
Similar to the memory code, the boot code is not following the Arm Arm and
could lead to memory corruption/TLB conflict abort. I am not aware
of any platforms where Xen fa
At the moment, the fixmap table is only hooked when earlyprintk is used.
This is fine today because in C land, the fixmap is not used by anyone
until the the boot CPU is switching to the runtime page-tables.
In the future, the boot CPU will not switch between page-tables to
avoid TLB incoherency.
On 17/09/2019 07:13, Jan Beulich wrote:
> There's no need for it to be 64 bits wide - only the low twelve bits
> of CR3 hold the PCID.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Roger Pau Monné
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xe
The 1:1 mapping may clash with other parts of the Xen virtual memory
layout. At the moment, Xen is handling the clash by only creating a
mapping to the runtime virtual address before enabling the MMU.
The rest of the mappings (such as the fixmap) will be mapped after the
MMU is enabled. However, t
Travis reports:
make subdirs-install
make[2]: Entering directory `/home/travis/build/andyhhp/xen/tools'
make[3]: Entering directory `/home/travis/build/andyhhp/xen/tools'
make -C libs install
make[4]: Entering directory `/home/travis/build/andyhhp/xen/tools/libs'
make[5]: Entering dire
Hi Stefano,
On 8/24/19 2:16 AM, Stefano Stabellini wrote:
On Mon, 12 Aug 2019, Julien Grall wrote:
lsr x2, x19, #THIRD_SHIFT /* Base address for 4K mapping */
lsl x2, x2, #THIRD_SHIFT
@@ -674,21 +591,80 @@ create_page_tables:
cmp x1, #(LPAE_ENTRIES<<3) /* 51
flight 141363 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141363/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 141322
Tests which did not
Anthony PERARD writes ("[PATCH 00/35] libxl refactoring to use ev_qmp (with API
changes)"):
> On the quest to have QEMU depriviledge, we need to make quite a few changes to
> libxl. This patch series rework quite a few libxl feature to use
> libxl__ev_qmp,
> which is the new asynchronous way of c
Anthony PERARD writes ("[PATCH 35/35] libxl: libxl_qemu_monitor_command now
uses ev_qmp"):
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/x
Anthony PERARD writes ("[PATCH 34/35] libxl:
libxl_retrieve_domain_configuration now uses ev_qmp"):
> This was the last user of libxl__qmp_query_cpus which can now be
> removed.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproje
Anthony PERARD writes ("[PATCH 33/35] libxl: Extract qmp_parse_query_cpus"):
> The QMP command "query-cpus" is called from different places, extract
> the algorithm that parse the answer into a separate function.
I hope you meant to write "No functional change."
If so, then with that added to the
Anthony PERARD writes ("[PATCH 32/35] libxl: Use ev_qmp in
libxl_set_vcpuonline"):
> Removed libxl__qmp_cpu_add since it's not used anymore.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/m
Anthony PERARD writes ("[PATCH 31/35] libxl: Use ev_qmp for
libxl_send_trigger"):
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Anthony PERARD writes ("[PATCH 30/35] libxl_pci: Use ev_qmp for pci_remove"):
> This patch also replaces the use of
> libxl__wait_for_device_model_deprecated() by its equivalent
> without the need for a thread.
>
> Signed-off-by: Anthony PERARD
> ---
>
> Notes:
> In do_pci_remove, instead of
Anthony PERARD writes ("[PATCH 29/35] libxl_pci: Use libxl__ao_device with
pci_remove"):
> This is in preparation of using asynchronous operation to communicate
> with QEMU via QMP (libxl__ev_qmp).
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-
Anthony PERARD writes ("[PATCH 28/35] libxl_pci: Use ev_qmp in do_pci_add"):
> This patch also replaces the use of
> libxl__wait_for_device_model_deprecated() by its equivalent
> without the need for a thread.
Again, would it be easy to add a pre-patch so I can see the code
changes ? If not I wil
On 16/09/2019 10:48, Jan Beulich wrote:
> XED commit 1b2fd94425 ("Update MOVSXD to modern behavior") points out
> that as of SDM rev 064 MOVSXD is specified to read only 16 bits from
> memory (or register) when used without REX.W and with operand size
> override. Since the upper 16 bits of the valu
Anthony PERARD writes ("[PATCH 27/35] libxl_pci: Use libxl__ao_device with
libxl__device_pci_add"):
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/l
Anthony PERARD writes ("[PATCH 25/35] libxl_pci: Coding style of do_pci_add"):
> do_pci_add is going to be asynchronous, so we start by having a single
> path out of the function. All `return`s instead set rc and goto out.
>
> While here, some use of `rc' was used to store the return value of
> li
Anthony PERARD writes ("[PATCH 26/35] libxl_pci: Only check if qemu-dm is
running in qemu-trad case"):
> QEMU upstream (or qemu-xen) may not have set "running" state in
> xenstore. "running" with QEMU doesn't mean that the binary is
> running, it means that the emulation have started. When adding
Anthony PERARD writes ("[PATCH 23/35] libxl:
libxl__initiate_device_usbdev_remove now use ev_qmp"):
> Signed-off-by: Anthony PERARD
...
> libxl_device_usbctrl usbctrl;
> +bool has_callback = false;
Not sure I like this encoding of program flow in a variable but it
seems correct, and it'
Anthony PERARD writes ("[PATCH 24/35] libxl: Remove
libxl__qmp_run_command_flexarray"):
> There are no more users.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Anthony PERARD writes ("[PATCH 22/35] libxl: Use aodev for
libxl__device_usbdev_remove"):
> This also mean libxl__initiate_device_usbctrl_remove, which uses
> libxl__device_usbdev_remove synchronously, needs to be updated to use
> it with multidev.
Acked-by: Ian Jackson
Anthony PERARD writes ("[PATCH 20/35] libxl_usb: Make
libxl__initiate_device_usbctrl_remove uses ev_qmp"):
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/ma
Anthony PERARD writes ("[PATCH 21/35] libxl_usb: Make libxl__device_usbdev_add
uses ev_qmp"):
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinf
Ian Jackson writes ("Re: [PATCH 06/35] libxl: Use ev_qmp for
switch_qemu_xen_logdirty"):
> Anthony PERARD writes ("[PATCH 06/35] libxl: Use ev_qmp for
> switch_qemu_xen_logdirty"):
> > Signed-off-by: Anthony PERARD
> ...
> > +rc = libxl__ev_time_register_rel(ao, &lds->timeout,
> > +
Anthony PERARD writes ("[PATCH 19/35] libxl_usb: Make libxl__device_usbctrl_add
uses ev_qmp"):
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listin
Anthony PERARD writes ("[PATCH 18/35] libxl: Add device_{config,type} to
libxl__ao_device"):
> These two fields help to give more information about the device been
> hotplug/hotunplug to callbacks.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-
Anthony PERARD writes ("[PATCH 17/35] libxl: Add libxl__ev_qmp to
libxl__ao_device"):
> `aodev->qmp' is initialised in libxl__prepare_ao_device(), but since
> there isn't a single exit path for a `libxl__ao_device', users of this
> new `qmp' field will have to disposed of it.
Acked-by: Ian Jackso
Anthony PERARD writes ("[PATCH 15/35] libxl: Inline do_usbdev_add into
libxl__device_usbdev_add"):
> Having the function do_usbdev_add makes it harder to add asynchronous
> calls into it. Move its body back into libxl__device_usbdev_add and
> adjust the latter as there are no reason to have a sepa
Anthony PERARD writes ("[PATCH 16/35] libxl: Inline do_usbdev_remove into
libxl__device_usbdev_remove"):
> Having the function do_usbdev_remove makes it harder to add asynchronous
> calls into it. Move its body back into libxl__device_usbdev_remove and
> adjust the latter as there are no reason to
Anthony PERARD writes ("[PATCH 14/35] libxl_domain: Convert
libxl_domain_unpause to use libxl__domain_unpause"):
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.
Anthony PERARD writes ("[PATCH 12/35] libxl: Re-introduce
libxl__domain_unpause"):
> libxl__domain_unpause is a reimplementation of
> libxl__domain_unpause_deprecated with asynchronous operation.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-de
Anthony PERARD writes ("[PATCH 13/35] libxl_dm: Update libxl__spawn_stub_dm to
use libxl__domain_unpause"):
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/m
Anthony PERARD writes ("[PATCH 11/35] libxl_domain: Convert libxl_domain_resume
to use libxl__domain_resume"):
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.or
Anthony PERARD writes ("[PATCH 10/35] libxl: Re-introduce
libxl__domain_resume"):
> libxl__domain_resume is a rework libxl__domain_resume_deprecated. It
> makes uses of ev_xswatch and ev_qmp, to replace synchronous QMP calls
> and libxl__wait_for_device_model_deprecated call.
Acked-by: Ian Jackso
Anthony PERARD writes ("[PATCH 09/35] libxl: Deprecate
libxl__domain_{unpause,resume}"):
> These two functions are used from many places in libxl and need to
> change to be able to accomodate libxl__ev_qmp calls and thus needs to
> be asynchronous.
>
> (There is also libxl__domain_resume_device_m
Anthony PERARD writes ("[PATCH 08/35] libxl: Replace libxl__qmp_initializations
by ev_qmp calls"):
> Setup a timeout of 10s for all the commands. It used to be about 5s
> per commands.
This patch is quite hard to review because it is a
rewrite/rearrangement and I can't see where all the pieces co
flight 141367 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141367/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 139910
test-amd64-i386-xl-q
Anthony PERARD writes ("[PATCH 07/35] libxl: Move "qmp_initializations" to
libxl_dm"):
> libxl__qmp_initializations is part of the device domain startup, it
> queries information about the newly spawned QEMU and do some
> post-startup configuration. So the function call doesn't belong to the
> gen
Ian Jackson writes ("Re: [PATCH 06/35] libxl: Use ev_qmp for
switch_qemu_xen_logdirty"):
> Anthony PERARD writes ("[PATCH 06/35] libxl: Use ev_qmp for
> switch_qemu_xen_logdirty"):
> > Signed-off-by: Anthony PERARD
> ...
> > +rc = libxl__ev_time_register_rel(ao, &lds->timeout,
> > +
Anthony PERARD writes ("[PATCH 06/35] libxl: Use ev_qmp for
switch_qemu_xen_logdirty"):
> Signed-off-by: Anthony PERARD
...
> +rc = libxl__ev_time_register_rel(ao, &lds->timeout,
> + switch_logdirty_timeout, 10 * 1000);
> +if (rc) goto out;
> +
> +q
Anthony PERARD writes ("[PATCH 05/35] libxl: Make libxl_qemu_monitor_command
async"):
> .. because it makes QMP calls which are going to be async.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject
Anthony PERARD writes ("[PATCH 03/35] libxl: Make libxl_set_vcpuonline async"):
> .. because it makes QMP calls which are going to be async.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/ma
Anthony PERARD writes ("[PATCH 04/35] libxl: Make
libxl_retrieve_domain_configuration async"):
> .. because it makes QMP calls which are going to be async.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.x
Anthony PERARD writes ("[PATCH 02/35] libxl: Make libxl_send_trigger async"):
> .. because it makes QMP calls which are going to be async.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mail
Anthony PERARD writes ("[PATCH 01/35] libxl: Make libxl_domain_unpause async"):
> libxl_domain_unpause needs to make QMP calls, which are asynchronous,
> change the API to reflect that.
>
> Do the same with libxl_domain_pause async, even if it will keep
> completing synchronously.
Jolly good. I
Anthony PERARD writes ("[PATCH 15/15] libxl_usb: Use usbctrl instead of
usbctrlinfo"):
> The functions that calls usbctrl_getinfo() only needs information that
> can be found in a `libxl_device_usbctrl'. So avoid calling
> libxl_device_usbctrl_getinfo and call libxl_devid_to_device_usbctrl
> inste
Anthony PERARD writes ("[PATCH 14/15] libxl_usb: usbctrl, make use of generic
device handling functions"):
> Two functions in generate `libxl_device_usbctrl' can be replaced by
> generic macro:
> - libxl_device_usbctrl_list -> LIBXL_DEFINE_DEVICE_LIST
> - libxl_devid_to_device_usbctrl -> LIBXL_DEF
Anthony PERARD writes ("[PATCH 13/15] libxl: Constify libxl_device_* param of
*_getinfo"):
> The libxl_device_TYPE parameter of all the libxl_device_TYPE_getinfo
> function seems to be only used as input to find more information to bi
> stored in the libxl_TYPEinfo parameter.
>
> Make sure this i
Anthony PERARD writes ("[PATCH 12/15] libxl_usb: Fix
libxl_device_usbctrl_getinfo"):
> `usbctrl' is modified in this function which doesn't seems to be
> intended, and usbctrlinfo.backend_id was never modified.
>
> Take this opportunity to consify the argument `usbctrl' in libxl API
> to avoid si
Anthony PERARD writes ("[PATCH 11/15] libxl_usb: Fix wrong usage of asserts"):
> Signed-off-by: Anthony PERARD
I'm not sure why you wouldn't just delete the breaks, rather than
replacing them "return" ?
Thanks,
Ian.
___
Xen-devel mailing list
Xen-deve
Anthony PERARD writes ("[PATCH 10/15] libxl_usb: Use proper domid value, from
libxl__device"):
> ao->domid isn't a reliable way of getting a domid, it might not be set
> (this isn't the case here). The right domid value can be found in the
> libxl__device (which is the device we want to remove) at
Anthony PERARD writes ("[PATCH 09/15] libxl_domain: Cleanup
libxl__destroy_domid"):
> - dom_path isn't used anymore in that function, remove it.
> - Use `r' to store return value of external calls.
> - Use `CTX', no need for a local `ctx'.
Acked-by: Ian Jackson
_
Anthony PERARD writes ("[PATCH 07/15] libxl_dm: Fix initialisation of
libxl__stub_dm_spawn_state"):
> sdss->pvqemu wasn't initialiased and disposed of properly.
> Also, move the initialisation of sdss->xswait with the rest of the
> initialisation of sdss.
Acked-by: Ian Jackson
_
Anthony PERARD writes ("[PATCH 08/15] libxl: Comment libxl__dm_spawn_state
aboud init and dispose"):
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/
Anthony PERARD writes ("[PATCH 04/15] libxl_pci: Constify arg `pcidev' of
libxl__device_pci_add_xenstore"):
> libxl__device_pci_add_xenstore doesn't modify `pcidev', so it can be
> constified. Also, we don't need pcidev_saved anymore, so remove the
> saved copy. (device_add_domain_config is going
Anthony PERARD writes ("[PATCH 05/15] libxl_pci: `starting' is a bool"):
> The argument `starting' is used as a boolean, change its type to
> reflex that throughout libxl_pci.c.
>
> No functional changes.
Acked-by: Ian Jackson
___
Xen-devel mailing li
Anthony PERARD writes ("[PATCH 06/15] libxl_dom_save: Reorder functions for
switch_qemu_logdirty"):
> Pure code motion.
I'll trust you on this :-).
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproje
Anthony PERARD writes ("[PATCH 03/15] libxl_pci: Make libxl__create_pci_backend
static"):
> libxl__create_pci_backend isn't called from outside of libxl_pci
> anymore, and it's only useful as part of the pci_add process, so
> remove the prototype from libxl_internal.h.
>
> No functional changes.
On 16/09/2019 10:48, Jan Beulich wrote:
> For some reason the Hygon enabling series left out the insn emulator.
> Make appropriate adjustments wherever we've been special casing AMD.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-de
Anthony PERARD writes ("[PATCH 02/15] libxl: Remove unused variable in
libxl__device_pci_add_xenstore"):
> *device isn't used.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinf
On 16/09/2019 14:56, Paul Durrant wrote:
>> -Original Message-
>> From: Wei Liu
>> Sent: 16 September 2019 14:29
>> To: Andrew Cooper
>> Cc: Paul Durrant ; Xen-devel
>> ; Jan Beulich
>> ; Wei Liu ; Roger Pau Monne
>>
>> Subject: Re: [PATCH] x86/viridian: Reword HV_X64_MSR_CRASH_CTL pri
Anthony PERARD writes ("[PATCH 01/15] libxl: Rename struct libxl_device_type to
libxl__device_type"):
> libxl__device_type is internal to libxl, rename it to the internal
> only prefix. And eliminate redundant 'struct' keyword, in accord with
> the coding style.
Acked-by: Ian Jackson
__
Anthony PERARD writes ("[PATCH v2 0/9] libxl: New slow lock + fix
libxl_cdrom_insert with QEMU depriv"):
> This patch series fix libxl_cdrom_insert to work with a depriviledge QEMU. For
> that, we need to use libxl__ev_qmp. For that, we need a new lock because
> userdata_lock can't be used anymor
On 9/17/19 6:09 PM, Tamas K Lengyel wrote:
> On Tue, Sep 17, 2019 at 8:24 AM Razvan Cojocaru
> wrote:
>>
>> On 9/17/19 5:11 PM, Alexandru Stefan ISAILA wrote:
>>> +bool hvm_monitor_check_p2m(unsigned long gla, gfn_t gfn, uint32_t pfec,
>>> + uint16_t kind)
>>>
Anthony PERARD writes ("[PATCH v2 6/9] libxl_disk: Cut libxl_cdrom_insert into
steps .."):
> .. and use a new "slow" lock to avoid holding the userdata lock across
> several functions.
>
> This patch cuts libxl_cdrom_insert into different step/function but
> there are still called synchronously.
The current implementations of xen_{map, unmap}_table() expect
{map, unmap}_domain_page() to be usable. Those helpers are used to
map/unmap page tables while update Xen page-tables.
Since commit 022387ee1a "xen/arm: mm: Don't open-code Xen PT update in
{set, clear}_fixmap()", setup_fixmap() will m
Anthony PERARD writes ("[PATCH v2 4/9] libxl: Add optimisation to ev_lock"):
> It will often be the case that the lock is free to grab. So we first
> try to grab it before we have to fork. Even though in this case the
> locks are grabbed in the wrong order in the lock hierarchy (ev_lock
> should be
Anthony PERARD writes ("[PATCH v2 3/9] libxl_internal: Introduce libxl__ev_lock
for devices hotplug via QMP"):
> The current lock `domain_userdata_lock' can't be used when modification
> to a guest is done by sending command to QEMU, this is a slow process
> and requires to call CTX_UNLOCK, which
On 17.09.2019 18:04, Jan Beulich wrote:
> On 17.09.2019 17:00, Alexandru Stefan ISAILA wrote:
>> There is no problem, I understand the risk of having suspicious return
>> values. I am not hanged on having this return. I used this to skip
>> adding a new return value. I can do this if we agree on
On 06/08/2019 14:11, Jan Beulich wrote:
> There's no point setting up tables with more space than a PCI device can
> use. For both MSI and MSI-X we can determine how many interrupts could
> be set up at most. Tables allocated during ACPI table parsing, however,
> will (for now at least) continue to
On Tue, Sep 17, 2019 at 8:24 AM Razvan Cojocaru
wrote:
>
> On 9/17/19 5:11 PM, Alexandru Stefan ISAILA wrote:
> > +bool hvm_monitor_check_p2m(unsigned long gla, gfn_t gfn, uint32_t pfec,
> > + uint16_t kind)
> > +{
> > +xenmem_access_t access;
> >
1 - 100 of 150 matches
Mail list logo