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
Reviewed-by: Roger Pau Monné
---
I can't see any technical or performance reason why we should treat
32-bit PV different from 64-bit PV in this regard.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -180,7 +180,24 @@ int switch_compat(struct domain *d)
Hi Peter,
Could you review this version?
Thank you,
On Fri, 6 Sep 2019 22:13:37 +0900
Masami Hiramatsu wrote:
> Hi,
>
> Here is the 4th version of patches to handle Xen/KVM emulate
> prefix by x86 instruction decoder.
>
> These patches allow x86 instruction decoder to decode
> Xen and KVM
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é
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -103,7 +103,8 @@ static void do_tlb_flush(void)
void switch_cr3_cr4(unsigned long
On 17.09.2019 09:09, Chao Gao wrote:
> On Fri, Sep 13, 2019 at 10:47:36AM +0200, Jan Beulich wrote:
>> On 12.09.2019 09:22, Chao Gao wrote:
>>> This series includes below changes:
>>> 1. Patch 1-11: introduce a global microcode cache and some cleanup
>>> 2. Patch 12: synchronize late microcode
Hi Paul,
On 9/16/19 10:27 AM, Paul Durrant wrote:
...and hence the ability to disable IOMMU mappings, and control EPT
sharing.
This patch introduces a new 'libxl_passthrough' enumeration into
libxl_domain_create_info. The value will be set by xl either when it parses
a new 'passthrough' option
The bit is meaningful only for MOV-to-CR3 insns, not anywhere else, in
particular not when loading nested guest state.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2080,6 +2080,8 @@ static int hvmemul_write_cr(
HVMTRACE_LONG_2D(CR_WRITE,
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é
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2325,7 +2325,7 @@ int hvm_set_cr3(unsigned long value, boo
}
if (
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 #GP(0) here is correct, but
that's not the
flight 141383 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141383/
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 Fri, Sep 13, 2019 at 10:47:36AM +0200, Jan Beulich wrote:
>On 12.09.2019 09:22, Chao Gao wrote:
>> This series includes below changes:
>> 1. Patch 1-11: introduce a global microcode cache and some cleanup
>> 2. Patch 12: synchronize late microcode loading
>> 3. Patch 13: support parallel
On 16.09.2019 18:58, Jan Beulich wrote:
> On 16.09.2019 10:10, Alexandru Stefan ISAILA wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -3224,6 +3224,14 @@ static enum hvm_translation_result __hvm_copy(
>> return HVMTRANS_bad_gfn_to_mfn;
>> }
On 17.09.2019 09:52, Alexandru Stefan ISAILA wrote:
> On 16.09.2019 18:58, Jan Beulich wrote:
>> On 16.09.2019 10:10, Alexandru Stefan ISAILA wrote:
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -3224,6 +3224,14 @@ static enum hvm_translation_result __hvm_copy(
>>>
On 17. Sep 2019, at 10:27, Jan Beulich
mailto:jbeul...@suse.com>> wrote:
On 16.09.2019 12:59, Pawel Wieczorkiewicz wrote:
@@ -951,11 +952,13 @@ struct xen_sysctl_livepatch_list {
amount of payloads and version.
> On 17. Sep 2019, at 10:48, Jan Beulich wrote:
>
> On 17.09.2019 10:40, Wieczorkiewicz, Pawel wrote:
>>
>>
>> On 17. Sep 2019, at 10:27, Jan Beulich
>> mailto:jbeul...@suse.com>> wrote:
>>
>> On 16.09.2019 12:59, Pawel Wieczorkiewicz wrote:
>> @@ -951,11 +952,13 @@ struct
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é
---
v2: Re-base over change earlier in the series.
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2296,10
This allows in particular some streamlining of the TLB flushing code
paths.
Signed-off-by: Jan Beulich
---
v2: Avoid #ifdef in cr3_pcid().
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -24,6 +24,11 @@
#define WRAP_MASK (0x03FFU)
#endif
+#ifndef CONFIG_PV
+# undef
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 expected as no other PCID
can be activated there.
On 16. Sep 2019, at 18:23, Ross Lagerwall
mailto:ross.lagerw...@citrix.com>> wrote:
On 9/16/19 11:59 AM, Pawel Wieczorkiewicz wrote:
This change is part of a independant stacked hotpatch modules
feature. This feature allows to bypass dependencies between modules
upon loading, but still
Julian,
The current status, as I said, is that the code has not been touched for many
years and I don’t actually know if it is functional against older versions of
Windows as it stands.
The kd protocol is a packet protocol and windbg is essentially in control;
issuing commands to dump
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 device */
>>> +void
On 17.09.2019 00:20, Joe Jin wrote:
> On 9/16/19 1:01 AM, Jan Beulich wrote:
>> On 13.09.2019 18:38, Joe Jin wrote:
>>> On 9/13/19 12:14 AM, Jan Beulich wrote:
On 12.09.2019 20:03, Joe Jin wrote:
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -412,6
On 16.09.2019 12:59, Pawel Wieczorkiewicz wrote:
> @@ -951,11 +952,13 @@ struct xen_sysctl_livepatch_list {
> amount of payloads and
> version.
> OUT: How many payloads left.
> */
> uint32_t pad;
On 16. Sep 2019, at 19:01, Ross Lagerwall
mailto:ross.lagerw...@citrix.com>> wrote:
On 9/16/19 11:59 AM, Pawel Wieczorkiewicz wrote:
snip
+/*
+ * Parse user provided action flags.
+ * This function expects to only receive an array of input parameters being
flags.
+ * Expected action is
On 17.09.2019 10:40, Wieczorkiewicz, Pawel wrote:
>
>
> On 17. Sep 2019, at 10:27, Jan Beulich
> mailto:jbeul...@suse.com>> wrote:
>
> On 16.09.2019 12:59, Pawel Wieczorkiewicz wrote:
> @@ -951,11 +952,13 @@ struct xen_sysctl_livepatch_list {
>
On Fri, Sep 13, 2019 at 11:22:59AM +0200, Jan Beulich wrote:
>On 12.09.2019 09:22, Chao Gao wrote:
>> @@ -283,6 +284,27 @@ static enum microcode_match_result compare_patch(
>> : OLD_UCODE;
>> }
>>
>> +static bool is_blacklisted(void)
Hi Paul,
On 9/16/19 9:34 AM, Paul Durrant wrote:
I guess this still needs ARM and toolstack acks?
For Arm bits:
Acked-by: Julien Grall
I am adding Anthony for the libxl.
Cheers,
-Original Message-
From: Paul Durrant
Sent: 13 September 2019 11:58
To:
flight 141358 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141358/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm broken
build-i386-xsm
On 9/17/19 10:12 AM, Wieczorkiewicz, Pawel wrote:
diff --git a/xen/include/xen/livepatch_payload.h
b/xen/include/xen/livepatch_payload.h
index 99613af2db..cd20944cc4 100644
--- a/xen/include/xen/livepatch_payload.h
+++ b/xen/include/xen/livepatch_payload.h
@@ -21,6 +21,16 @@ typedef struct
Hi Paul,
On 9/13/19 11:58 AM, Paul Durrant wrote:
Now that there is a per-domain IOMMU-enable flag, which should be set if
any device is going to be passed through, stop deferring page table
construction until the assignment is done. Also don't tear down the tables
again when the last device is
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 7:48 PM, Volodymyr Babchuk wrote:
Julien Grall writes:
Hi Volodymyr,
On 8/23/19
On 17.09.2019 11:01, Chao Gao wrote:
> On Fri, Sep 13, 2019 at 11:22:59AM +0200, Jan Beulich wrote:
>> On 12.09.2019 09:22, Chao Gao wrote:
>>> --- a/xen/include/asm-x86/microcode.h
>>> +++ b/xen/include/asm-x86/microcode.h
>>> @@ -30,6 +30,7 @@ struct microcode_ops {
>>> bool
Hi Jan,
On 9/13/19 12:10 PM, Jan Beulich wrote:
This patch defines a new bit reported in the hw_cap field of struct
xen_sysctl_physinfo to indicate whether the platform supports sharing of
HAP page tables (i.e. the P2M) with the IOMMU. This informs the toolstack
whether the domain needs extra
Hi Paul,
On 9/13/19 11:58 AM, Paul Durrant wrote:
Thes macros really ought to live in the common xen/iommu.h header rather
then being distributed amongst architecture specific iommu headers and
xen/sched.h. This patch moves them there.
NOTE: Disabling 'sharept' in the command line iommu
flight 141388 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141388/
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 16. Sep 2019, at 19:54, Ross Lagerwall wrote:
>
>>
snip
>> 2) post-apply hook
>> runs after the apply action has been executed and quiescing zone
>> exited. Its main purpose is to provide an ability to follow-up on
>> actions performed by the pre- hook, when module application was
Hi Stewart,
On 9/14/19 2:22 AM, Stewart Hildebrand wrote:
On Friday, September 13, 2019 5:42 PM, Julien Grall
wrote:
Hi,
On 9/13/19 8:11 PM, Stewart Hildebrand wrote:
Upstream Linux kernel will use "brcm,bcm2711" as the compatible string
for Raspberry Pi 4 [1]. Add this string to our
(+ Juergen)
Hi,
On 9/16/19 9:51 AM, Jan Beulich wrote:
On 15.09.2019 19:51, Julien Grall wrote:
Hi,
On 9/15/19 3:09 PM, osstest service owner wrote:
flight 141333 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141333/
Regressions :-(
Tests which did not
On 06/08/2019 14:09, Jan Beulich wrote:
> ACPI tables are free to list far more device coordinates than there are
> actual devices. By delaying the table allocations for most cases, and
> doing them only when an actual device is known to be present at a given
> position, overall memory used for
On 06/08/2019 14:08, Jan Beulich wrote:
> Calling amd_iommu_free_intremap_table() for every IVRS entry is correct
> only in per-device-IRT mode. Use a NULL 2nd argument to indicate that
> the shared table should be freed, and call the function exactly once in
> shared mode.
>
> Signed-off-by: Jan
On 06/08/2019 14:09, Jan Beulich wrote:
> Additional users of the function will want to handle errors more
> gracefully. Remove the BUG_ON()s and make the current caller panic()
> instead.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
On 17.09.2019 14:45, Paul Durrant wrote:
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 17 September 2019 07:15
>>
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -2080,6 +2080,8 @@ static int hvmemul_write_cr(
>> HVMTRACE_LONG_2D(CR_WRITE, reg,
On 06/08/2019 14:09, Jan Beulich wrote:
> Rather than duplicating entries in amd_iommu_msi_msg_update_ire(), share
> the tables. This mainly requires some care while freeing them, to avoid
> freeing memory blocks twice.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
After commit 6e3e771203 "xen/arm: setup: Relocate the Device-Tree later on
in the boot", the boot allocator will not receive any xenheap page (i.e.
mapped page) on Arm32.
However, the boot allocator implicitely rely on having the first page
already mapped and therefore result to break boot on
Hi Juergen,
On 9/17/19 2:12 PM, Juergen Gross wrote:
On 17.09.19 14:31, Julien Grall wrote:
(+ Juergen)
Hi,
On 9/16/19 9:51 AM, Jan Beulich wrote:
On 15.09.2019 19:51, Julien Grall wrote:
Hi,
On 9/15/19 3:09 PM, osstest service owner wrote:
flight 141333 xen-unstable-smoke real [real]
On 06/08/2019 14:10, Jan Beulich wrote:
> Rather than doing this every time we set up interrupts for a device
> anew (and then in two distinct places) fill this invariant field
> right after allocating struct arch_msix.
>
> While at it also obtain the MSI-X capability structure position just
>
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 06/08/2019 14:08, Jan Beulich wrote:
> For us to no longer blindly allocate interrupt remapping tables for
> everything the ACPI tables name, we can't use struct ivrs_mappings'
> intremap_table field anymore to also have the meaning of "this entry
> is valid". Add a separate boolean field
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 17 September 2019 07:15
> To: xen-devel@lists.xenproject.org
> Cc: Kevin Tian ; Suravee Suthikulpanit
> ; Wei Liu
> ; Paul Durrant ; George Dunlap
> ; Andrew Cooper
> ; Jun Nakajima ; Boris
> Ostrovsky
> ; Roger
On Fri, 13 Sep 2019 at 11:58, Paul Durrant wrote:
>
> This patch defines a new bit reported in the hw_cap field of struct
> xen_sysctl_physinfo to indicate whether the platform supports sharing of
> HAP page tables (i.e. the P2M) with the IOMMU. This informs the toolstack
> whether the domain
On Tue, Sep 17, 2019 at 08:55:22AM +, Wieczorkiewicz, Pawel wrote:
>
>
> > On 17. Sep 2019, at 10:48, Jan Beulich wrote:
> >
> > On 17.09.2019 10:40, Wieczorkiewicz, Pawel wrote:
> >>
> >>
> >> On 17. Sep 2019, at 10:27, Jan Beulich
> >> mailto:jbeul...@suse.com>> wrote:
> >>
> >> On
On 17.09.19 14:31, Julien Grall wrote:
(+ Juergen)
Hi,
On 9/16/19 9:51 AM, Jan Beulich wrote:
On 15.09.2019 19:51, Julien Grall wrote:
Hi,
On 9/15/19 3:09 PM, osstest service owner wrote:
flight 141333 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141333/
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
___
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 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
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
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
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
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,
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
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
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,
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
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
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.
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
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
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: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: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
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
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 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
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
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
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
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 ->
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 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
>
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
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
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 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 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)
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
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, >timeout,
> > +
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
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
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
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
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
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
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
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 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
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 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
>
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, >timeout,
> > +
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
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
1 - 100 of 161 matches
Mail list logo
