On Fri, Jan 25, 2019 at 09:45:26AM +, Peng Fan wrote:
> Just have a question,
>
> Since vmalloc_to_page is ok for cma area, no need to take cma and per device
> cma into consideration right?
The CMA area itself it a physical memory region. If it is a non-highmem
region you can call virt_to
Andrii,
Thank you for your previous mail.
I am sorry for taking so long to answer.
The rest of the mail is inline
2019年1月22日(火) 18:00 Andrii Anisov :
>
>
> On 22.01.19 12:45, LOPEZ, FUENTES NACARINO Jairo Eduardo wrote:
> > Yes. Since you pointed out that the U-boot version was not what you
>
>>> On 28.01.19 at 08:56, wrote:
> On 1/28/19 08:35, Jan Beulich wrote:
> On 27.01.19 at 21:28, wrote:
>>> On 1/25/19 14:09, Jan Beulich wrote:
>>> On 25.01.19 at 11:50, wrote:
> On 1/25/19 11:14, Jan Beulich wrote:
> On 24.01.19 at 22:29, wrote:
>>> Worse is the "evalua
Hello Jairo,
On 28.01.19 19:20, LOPEZ, FUENTES NACARINO Jairo Eduardo wrote:
I was able to compile the Xen image with earlyprintk without issue.
Cool.
It is comforting to get some sort of feedback from the device, even if it is
failing.
Indeed:)
When attempting to boot the Xen image cr
Jürgen,
>>> On 23.01.19 at 12:51, wrote:
> This patch series attempts to mitigate the issue that have been raised in the
> XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
> execution on Intel hardware, an lfence instruction is required to make sure
> that selected ch
+Boris and Juergen who can also help getting it in
On 1/28/19 8:34 AM, Souptick Joarder wrote:
On Mon, Jan 14, 2019 at 4:08 PM Oleksandr Andrushchenko
wrote:
On 1/7/19 7:37 PM, Souptick Joarder wrote:
Remove duplicate header which is included twice.
Signed-off-by: Souptick Joarder
Reviewed
On 28/01/2019 09:28, Jan Beulich wrote:
> Jürgen,
>
On 23.01.19 at 12:51, wrote:
>> This patch series attempts to mitigate the issue that have been raised in the
>> XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
>> execution on Intel hardware, an lfence instruc
On Fri, 25 Jan 2019 19:06:02 +0200
Andrii Anisov wrote:
> From: Andrii Anisov
>
> Currently, that assert condition does not correspond to a comment
> above and makes assertion failed on HW IRQ disconnection.
> Fix the condition so it corresponds to the comment and allows IRQ
> disconnection on
The increased number of messages (spec_ctrl.c:print_details()) within a
certain time window made me notice some slowness of boot time screen
output. Experimentally I've narrowed the time window to be from
immediately after the early ucode update on the BSP to the PAT write in
cpu_init(), which upon
>>> On 28.01.19 at 09:47, wrote:
> On 28/01/2019 09:28, Jan Beulich wrote:
> On 23.01.19 at 12:51, wrote:
>>> This patch series attempts to mitigate the issue that have been raised in
>>> the
>>> XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block
>>> speculative
>>> execution
> -Original Message-
> From: Tian, Kevin [mailto:kevin.t...@intel.com]
> Sent: 28 January 2019 02:34
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Andrew Cooper
> ; Wei Liu ; Roger Pau
> Monne ; Nakajima, Jun
> Subject: RE: [PATCH 2/6] x86: save GUEST_BNDCFGS on c
On 28/01/2019 10:56, Jan Beulich wrote:
On 28.01.19 at 09:47, wrote:
>> On 28/01/2019 09:28, Jan Beulich wrote:
>> On 23.01.19 at 12:51, wrote:
This patch series attempts to mitigate the issue that have been raised in
the
XSA-289 (https://xenbits.xen.org/xsa/advisory-289.
On 1/28/19 09:24, Jan Beulich wrote:
On 28.01.19 at 08:56, wrote:
>> On 1/28/19 08:35, Jan Beulich wrote:
>> On 27.01.19 at 21:28, wrote:
On 1/25/19 14:09, Jan Beulich wrote:
On 25.01.19 at 11:50, wrote:
>> On 1/25/19 11:14, Jan Beulich wrote:
>> On 24.01.19 at
On 1/28/19 9:42 AM, Andre Przywara wrote:
On Fri, 25 Jan 2019 19:06:02 +0200
Andrii Anisov wrote:
From: Andrii Anisov
Currently, that assert condition does not correspond to a comment
above and makes assertion failed on HW IRQ disconnection.
Fix the condition so it corresponds to the comment
Hi,
On 1/26/19 1:30 AM, Stefano Stabellini wrote:
On Mon, 21 Jan 2019, Julien Grall wrote:
Hi,
Ping?
Cheers,
On 30/11/2018 17:25, Julien Grall wrote:
Hi,
Below a list of backport candidate for Arm.
For Xen 4.10+ to handle correctly SMC call parameters and result
35fc608612 xen/arm: s
On 1/25/19 17:34, Jan Beulich wrote:
On 23.01.19 at 12:57, wrote:
>> @@ -66,6 +67,9 @@ static struct hvm_vioapic *gsi_vioapic(const struct domain
>> *d,
>> {
>> unsigned int i;
>>
>> +/* Make sure the compiler does not optimize the initialization */
>> +OPTIMIZER_HIDE_VAR(pin
On 1/27/19 9:55 AM, Julien Grall wrote:
Hi,
On 1/25/19 9:36 PM, Stefano Stabellini wrote:
On Thu, 24 Jan 2019, Julien Grall wrote:
@James, please correct me if I am wrong below :).
On 24/01/2019 00:52, Stefano Stabellini wrote:
On Wed, 28 Nov 2018, Julien Grall wrote:
... in the context of
>>> On 28.01.19 at 12:03, wrote:
> On 1/25/19 17:34, Jan Beulich wrote:
> On 23.01.19 at 12:57, wrote:
>>> @@ -212,7 +217,12 @@ static void vioapic_write_redirent(
>>> struct hvm_irq *hvm_irq = hvm_domain_irq(d);
>>> union vioapic_redir_entry *pent, ent;
>>> int unmasked = 0;
>
>>> On 24.01.19 at 03:04, wrote:
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -148,3 +148,5 @@
> ?flask_setenforcexsm/flask_op.h
> !flask_sid_context xsm/flask_op.h
> ?flask_transitionxsm/flask_op.h
> +?argo_addr
>>> On 24.01.19 at 03:04, wrote:
> @@ -31,13 +32,27 @@
> #ifdef CONFIG_COMPAT
> #include
> CHECK_argo_addr;
> +CHECK_argo_register_ring;
> CHECK_argo_ring;
> #endif
What about struct xen_argo_ring_message_header?
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -150,3 +150,4
>>> On 24.01.19 at 03:04, wrote:
> --- a/xen/common/argo.c
> +++ b/xen/common/argo.c
> @@ -32,16 +32,24 @@
> #ifdef CONFIG_COMPAT
> #include
> CHECK_argo_addr;
> +#undef CHECK_argo_addr
> +#define CHECK_argo_addr struct xen_argo_addr
> CHECK_argo_register_ring;
> CHECK_argo_ring;
> CHECK_ar
>>> On 17.01.19 at 15:57, wrote:
> @@ -83,3 +84,9 @@ subdir-$(CONFIG_UBSAN) += ubsan
>
> subdir-$(CONFIG_NEEDS_LIBELF) += libelf
> subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt
> +
> +config_data.c: ../.config
> + ( echo "const char xen_config_data[] ="; \
> + cat $< | gzip | ../tools/b
On 28/01/2019 09:51, Jan Beulich wrote:
> The increased number of messages (spec_ctrl.c:print_details()) within a
> certain time window made me notice some slowness of boot time screen
> output. Experimentally I've narrowed the time window to be from
> immediately after the early ucode update on th
>>> On 28.01.19 at 12:40, wrote:
On 17.01.19 at 15:57, wrote:
>> @@ -83,3 +84,9 @@ subdir-$(CONFIG_UBSAN) += ubsan
>>
>> subdir-$(CONFIG_NEEDS_LIBELF) += libelf
>> subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt
>> +
>> +config_data.c: ../.config
>> +( echo "const char xen_config_data[] =
Signed-off-by: Julien Grall
---
xen/arch/arm/cpuerrata.c | 10 ++
xen/arch/arm/p2m.c | 2 ++
2 files changed, 12 insertions(+)
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 4431b244fd..727c67451d 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpu
A follow-up patch will require to allocate the root page-table without
having a domain in hand.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- Add Andrii's and Stefano's reviewed-by
---
xen/arch/arm/p2m.c | 16 ++
A follow-up patch will need to generate the VTTBR in a few places.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- Add Andrii's and Stefano's reviewed-by
---
xen/arch/arm/p2m.c | 7 ++-
1 file changed, 6 insertions(+)
Early version of Cortex-A76 can end-up with corrupt TLBs if they
speculate an AT instruction while the S1/S2 system registers are in an
inconsistent state.
This can happen during guest context switch and when invalidating the
TLBs for other than the current VMID.
The workaround implemented in Xen
Hi all,
Early version of Cortex-A76 can end-up with corrupt TLBs if they
speculate an AT instruction while the S1/S2 system registers are in an
inconsistent state.
This can happen during guest context switch and when invalidating the
TLBs for other than the current VMID.
The workaround implement
The EL1 translation regime is out-of-context when running at EL2. This
means the processor cannot speculate memory accesses using the registers
associated to that regime.
An isb() is only needed if Xen is going to use the translation regime
before returning to the guest (exception returns will syn
Only {A,F,I}MO are necessary to receive interrupts until a guest vCPU is
loaded.
The rest have no effect on Xen and it is better to avoid setting them.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- Fix typo
- Ad
Until recently, kernel/initrd/dtb were loaded using guest VA and
therefore requiring to restore temporarily the P2M. This was reworked
in a series of commits (up to 9292086 "xen/arm: domain_build: Use
copy_to_guest_phys_flush_dcache in dtb_load") to use a guest PA.
This will also help a follow-up
On Fri, Jan 25, 2019 at 09:13:49AM -0700, Jan Beulich wrote:
On 25.01.19 at 09:26, wrote:
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -732,7 +732,11 @@ long arch_do_domctl(
>> break;
>>
>> ret = -EPERM;
>> -if ( irq <= 0 || !irq_access_p
On 25/01/2019 18:06, Andrii Anisov wrote:
> From: Andrii Anisov
>
> Currently, that assert condition does not correspond to a comment above
> and makes assertion failed on HW IRQ disconnection.
> Fix the condition so it corresponds to the comment and allows IRQ
> disconnection on debug builds.
>
On 28/01/2019 12:50, Julien Grall wrote:
> Hi all,
>
> Early version of Cortex-A76 can end-up with corrupt TLBs if they
> speculate an AT instruction while the S1/S2 system registers are in an
> inconsistent state.
>
> This can happen during guest context switch and when invalidating the
> TLBs f
On 28/01/2019 10:51, Jan Beulich wrote:
> The increased number of messages (spec_ctrl.c:print_details()) within a
> certain time window made me notice some slowness of boot time screen
> output. Experimentally I've narrowed the time window to be from
> immediately after the early ucode update on th
On 24/01/2019 13:29, Anthony PERARD wrote:
> Since libxl later during guest creation run the command "cont", it kind
> of expect that QEMU would not do any emulation, use the "-S" command
> option to make this effective. Unfortunately, when QEMU is started with
> "-S", it won't write QEMU's readine
On Sat, Jan 26, 2019 at 10:45:07PM -0700, Tamas K Lengyel wrote:
> On systems with XSM enabled libxl_name_to_domid leaks memory
> allocated for ssid_label:
>
> ==2693== 53 bytes in 2 blocks are definitely lost in loss record 4 of 8
> ==2693==at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
> ==2
On 24/01/2019 13:43, Peng Fan wrote:
> On i.MX8, we implemented partition reboot which means Cortex-A reboot
> will not impact M4 cores and System control Unit core. However GICv3
> is not reset because we also need to support A72 Cluster reboot without
> affecting A53 Cluster.
>
> The gic-v3 cont
On 1/28/19 12:12, Jan Beulich wrote:
On 28.01.19 at 12:03, wrote:
>> On 1/25/19 17:34, Jan Beulich wrote:
>> On 23.01.19 at 12:57, wrote:
@@ -212,7 +217,12 @@ static void vioapic_write_redirent(
struct hvm_irq *hvm_irq = hvm_domain_irq(d);
union vioapic_redir_ent
This is a note to let you know that I've just added the patch titled
x86/entry/64/compat: Fix stack switching for XEN PV
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
x86
This is a note to let you know that I've just added the patch titled
x86/entry/64/compat: Fix stack switching for XEN PV
to the 4.20-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
x86
On Thu, Jan 17, 2019 at 05:40:59PM +0100, Juergen Gross wrote:
> In case of soft reset the gnttab limit setting will fail, so omit it.
> Setting of max vcpu count is pointless in this case, too, so we can
> drop that as well.
>
> Without this patch soft reset will fail with:
>
> libxl: error: lib
On Fri, Jan 25, 2019 at 12:33:49AM -0700, Jan Beulich wrote:
> Commit fd35f32b4b ("tools/x86emul: Use struct cpuid_policy in the
> userspace test harnesses") didn't account for the dependencies of
> cpuid-autogen.h to potentially change between incremental builds.
> Putting the make invocation to p
On Fri, Jan 25, 2019 at 12:34:18AM -0700, Jan Beulich wrote:
> Commit fd35f32b4b ("tools/x86emul: Use struct cpuid_policy in the
> userspace test harnesses") didn't account for the dependencies of
> cpuid-autogen.h to potentially change between incremental builds.
> In particular the harness has a
Before the cpuid_policy logic came along, %cr4 auditing on migrate-in was
complicated, because at that point no CPUID information had been set for the
guest. Auditing against the host CPUID was better than nothing, but not
ideal.
Order of information in the migration stream is still an issue (hen
On 1/24/19 22:05, Andrew Cooper wrote:
> On 23/01/2019 11:51, Norbert Manthey wrote:
>> Dear all,
>>
>> This patch series attempts to mitigate the issue that have been raised in the
>> XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
>> execution on Intel hardware, an l
>>> On 28.01.19 at 12:40, wrote:
> On 28/01/2019 09:51, Jan Beulich wrote:
>> The increased number of messages (spec_ctrl.c:print_details()) within a
>> certain time window made me notice some slowness of boot time screen
>> output. Experimentally I've narrowed the time window to be from
>> immedi
The current GSI mapping code can cause the following deadlock:
(XEN) *** Dumping CPU0 host state: ***
(XEN) [ Xen-4.12.0-rc x86_64 debug=y Tainted: C ]
[...]
(XEN) Xen call trace:
(XEN)[] vmac.c#_spin_lock_cb+0x32/0x70
(XEN)[] vmac.c#hvm_gsi_assert+0x2f/0x60 <- pick
hvm.irq
On Sat, Jan 26, 2019 at 03:31:13AM +0100, Marek Marczykowski-Górecki wrote:
> When qemu is running in stubdomain, handling "pci-ins" command will fail
> if pcifront is not initialized already. Fix this by sending such command
> only after confirming that pciback/front is running.
>
> Signed-off-by
On Sat, Jan 26, 2019 at 03:31:12AM +0100, Marek Marczykowski-Górecki wrote:
> HVM domains use IOMMU and device model assistance for communicating with
> PCI devices, xen-pcifront/pciback isn't directly needed by HVM domain.
> But pciback serve also second function - it reset the device when it is
>
On 28/01/2019 14:19, Jan Beulich wrote:
>>> --- a/xen/arch/x86/microcode_amd.c
>>> +++ b/xen/arch/x86/microcode_amd.c
>>> @@ -218,6 +218,12 @@ static int apply_microcode(unsigned int
>>>
>>> spin_unlock_irqrestore(µcode_update_lock, flags);
>>>
>>> +/*
>>> + * Experimentally this h
On Sat, Jan 26, 2019 at 03:31:14AM +0100, Marek Marczykowski-Górecki wrote:
> Stubdomain do not have it's own config file - its configuration is
> derived from target domains. Do not try to manipulate it when attaching
> PCI device.
>
So if we add the same configuration to stubdom as well, what w
On Sat, Jan 26, 2019 at 03:31:17AM +0100, Marek Marczykowski-Górecki wrote:
> Add libxc wrapper for PHYSDEVOP_msi_msix_set_enable introduced in
> previous commit.
>
> Signed-off-by: Marek Marczykowski-Górecki
Assuming the addition of physdev ops is accepted:
Acked-by: Wei Liu
On 1/23/19 14:37, Jan Beulich wrote:
On 23.01.19 at 12:51, wrote:
>> @@ -1268,7 +1272,8 @@ unmap_common(
>> }
>>
>> smp_rmb();
>> -map = &maptrack_entry(lgt, op->handle);
>> +map = &maptrack_entry(lgt, array_index_nospec(op->handle,
>> +
On Sat, Jan 26, 2019 at 03:31:15AM +0100, Marek Marczykowski-Górecki wrote:
> From: Simon Gaiser
>
> Stubdomains need to be given sufficient privilege over the guest which it
> provides emulation for in order for PCI passthrough to work correctly.
> When a HVM domain try to enable MSI, QEMU in st
On Sat, Jan 26, 2019 at 03:31:16AM +0100, Marek Marczykowski-Górecki wrote:
> Allow device model running in stubdomain to enable/disable MSI(-X),
> bypassing pciback. While pciback is still used to access config space
> from within stubdomain, it refuse to write to
> PCI_MSI_FLAGS_ENABLE/PCI_MSIX_F
>>> On 28.01.19 at 15:45, wrote:
> On 1/23/19 14:37, Jan Beulich wrote:
> On 23.01.19 at 12:51, wrote:
>>> @@ -2223,7 +2231,8 @@ gnttab_transfer(
>>> okay = gnttab_prepare_for_transfer(e, d, gop.ref);
>>> spin_lock(&e->page_alloc_lock);
>>>
>>> -if ( unlikely(!okay
On Mon, Jan 28, 2019 at 03:22:45PM +0100, Roger Pau Monne wrote:
> The current GSI mapping code can cause the following deadlock:
>
> (XEN) *** Dumping CPU0 host state: ***
> (XEN) [ Xen-4.12.0-rc x86_64 debug=y Tainted: C ]
> [...]
> (XEN) Xen call trace:
> (XEN)[] vmac.c#_spin
On Mon, Jan 28, 2019 at 01:56:29PM +, Andrew Cooper wrote:
> Before the cpuid_policy logic came along, %cr4 auditing on migrate-in was
> complicated, because at that point no CPUID information had been set for the
> guest. Auditing against the host CPUID was better than nothing, but not
> idea
>>> On 28.01.19 at 14:56, wrote:
> Before the cpuid_policy logic came along, %cr4 auditing on migrate-in was
> complicated, because at that point no CPUID information had been set for the
> guest. Auditing against the host CPUID was better than nothing, but not
> ideal.
>
> Order of information
On 28/01/2019 15:22, Wei Liu wrote:
> On Mon, Jan 28, 2019 at 01:56:29PM +, Andrew Cooper wrote:
>> Before the cpuid_policy logic came along, %cr4 auditing on migrate-in was
>> complicated, because at that point no CPUID information had been set for the
>> guest. Auditing against the host CPUI
>>> On 28.01.19 at 15:22, wrote:
> In order to solve it move the vioapic_hwdom_map_gsi outside of the
> locked region in vioapic_write_redirent. vioapic_hwdom_map_gsi will
> not access any of the vioapic fields, so there's no need to call the
> function holding the hvm.irq_lock.
True, but you als
From: Andrii Anisov
In case if the p2m table is shared to IOMMU, invalidating it turns IOMMU to
translation faults that could be not repaired.
Fixed patch check for the corresponded condition and has a comment for one
introduced p2m_invalidate_root() call, but miss them for another. So put the
`
On 28/01/2019 15:22, Jan Beulich wrote:
On 28.01.19 at 14:56, wrote:
>> Before the cpuid_policy logic came along, %cr4 auditing on migrate-in was
>> complicated, because at that point no CPUID information had been set for the
>> guest. Auditing against the host CPUID was better than nothing,
>>> On 28.01.19 at 16:36, wrote:
> On 28/01/2019 15:22, Jan Beulich wrote:
> On 28.01.19 at 14:56, wrote:
>>> Before the cpuid_policy logic came along, %cr4 auditing on migrate-in was
>>> complicated, because at that point no CPUID information had been set for the
>>> guest. Auditing against
On 1/28/19 8:25 AM, Andrew Cooper wrote:
> On 28/01/2019 14:19, Jan Beulich wrote:
--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -218,6 +218,12 @@ static int apply_microcode(unsigned int
spin_unlock_irqrestore(µcode_update_lock, flags);
>
On Mon, Jan 28, 2019 at 08:30:02AM -0700, Jan Beulich wrote:
> >>> On 28.01.19 at 15:22, wrote:
> > In order to solve it move the vioapic_hwdom_map_gsi outside of the
> > locked region in vioapic_write_redirent. vioapic_hwdom_map_gsi will
> > not access any of the vioapic fields, so there's no nee
On 28/01/2019 15:50, Jan Beulich wrote:
On 28.01.19 at 16:36, wrote:
>> On 28/01/2019 15:22, Jan Beulich wrote:
>> On 28.01.19 at 14:56, wrote:
Before the cpuid_policy logic came along, %cr4 auditing on migrate-in was
complicated, because at that point no CPUID information had
Hi,
On 1/28/19 3:34 PM, Andrii Anisov wrote:
From: Andrii Anisov
In case if the p2m table is shared to IOMMU, invalidating it turns IOMMU to
translation faults that could be not repaired.
Fixed patch check for the corresponded condition and has a comment for one
introduced p2m_invalidate_root
flight 132499 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132499/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 132451
Tests which did not
While SPIs are shared between CPU, it is not possible to receive the
same interrupts on a different CPU while the interrupt is in active
state. The deactivation of the interrupt is done at the end of the
handling.
This means the _IRQ_PENDING logic is unecessary on Arm as a same
interrupt can never
no_irq_type handlers are used when an IRQ does not have action attached.
This is useful to detect misconfiguration between the interrupt
controller and the software.
Currently, all the handlers will do nothing on spurious interrupt. This
means if such interrupt is received, the priority of the int
>>> On 28.01.19 at 16:52, wrote:
> On Mon, Jan 28, 2019 at 08:30:02AM -0700, Jan Beulich wrote:
>> >>> On 28.01.19 at 15:22, wrote:
>> > In order to solve it move the vioapic_hwdom_map_gsi outside of the
>> > locked region in vioapic_write_redirent. vioapic_hwdom_map_gsi will
>> > not access any
Hello Julien,
Actually I was going to send this patch as RFC, but dropped it at the last
moment.
On 28.01.19 17:55, Julien Grall wrote:
This was missed on purpose. Let me explain why. The call to
p2m_invalidate_root() arch_domain_creation_finished is called by *all* the
domain at boot to try
On 1/28/19 4:32 PM, Andrii Anisov wrote:
Hello Julien,
Actually I was going to send this patch as RFC, but dropped it at the
last moment.
On 28.01.19 17:55, Julien Grall wrote:
This was missed on purpose. Let me explain why. The call to
p2m_invalidate_root() arch_domain_creation_finished i
On 28.01.19 18:36, Julien Grall wrote:
Hold on, CA57 and CA53 are ARMv8 cores. So are you using 32-bit or 64-bit
guests?
64-bit guests.
64-bit guest should not have any Set/Way operations unless you are using a very
very old Linux. So what is the version of each guest?
All of them derived
On Mon, Jan 28, 2019 at 03:06:43PM +0800, Chao Gao wrote:
> This check has been done in microcode_sanity_check(). Needn't do it
> again in get_matching_microcode().
>
> Signed-off-by: Chao Gao
Reviewed-by: Roger Pau Monné
Thanks, Roger.
___
Xen-deve
Before the cpuid_policy logic came along, %cr4/EFER auditing on migrate-in was
complicated, because at that point no CPUID information had been set for the
guest. Auditing against the host CPUID was better than nothing, but not
ideal.
Similarly at the time, PVHv1 lacked the "CPUID passed through
>>> On 28.01.19 at 17:40, wrote:
> Before the cpuid_policy logic came along, %cr4/EFER auditing on migrate-in was
> complicated, because at that point no CPUID information had been set for the
> guest. Auditing against the host CPUID was better than nothing, but not
> ideal.
>
> Similarly at the
On Mon, Jan 28, 2019 at 04:40:59PM +, Andrew Cooper wrote:
> Before the cpuid_policy logic came along, %cr4/EFER auditing on migrate-in was
> complicated, because at that point no CPUID information had been set for the
> guest. Auditing against the host CPUID was better than nothing, but not
>
On 1/28/19 4:40 PM, Andrii Anisov wrote:
On 28.01.19 18:36, Julien Grall wrote:
Hold on, CA57 and CA53 are ARMv8 cores. So are you using 32-bit or
64-bit guests?
64-bit guests.
64-bit guest should not have any Set/Way operations unless you are
using a very very old Linux. So what is the v
On Mon, Jan 28, 2019 at 03:06:44PM +0800, Chao Gao wrote:
> to a more generic function. Then, this function can compare two given
> microcodes' signature/revision as well. Comparing two microcodes is
> used to update the global microcode cache (introduced by the later
> patches in this series) when
On 28.01.19 18:54, Julien Grall wrote:
On 1/28/19 4:40 PM, Andrii Anisov wrote:
On 28.01.19 18:36, Julien Grall wrote:
Hold on, CA57 and CA53 are ARMv8 cores. So are you using 32-bit or 64-bit
guests?
64-bit guests.
64-bit guest should not have any Set/Way operations unless you are us
>>> On 28.01.19 at 17:55, wrote:
> On Mon, Jan 28, 2019 at 03:06:44PM +0800, Chao Gao wrote:
>> to a more generic function. Then, this function can compare two given
>> microcodes' signature/revision as well. Comparing two microcodes is
>> used to update the global microcode cache (introduced by t
On Mon, Jan 28, 2019 at 03:06:45PM +0800, Chao Gao wrote:
> to replace the current per-cpu cache 'uci->mc'.
>
> Compared to the current per-cpu cache, the benefits of the global
> microcode cache are:
> 1. It reduces the work that need to be done on each CPU. Parsing ucode
> file can be done once
On Sun, Jan 27, 2019 at 02:15:52PM -0800, Pry Mar wrote:
> qemu build config:
> http://paste.debian.net/plain/1062777/
>
> domU startup trace:
> http://paste.debian.net/plain/1062768/
>
> This release uses qemu-3.0.0 which has a depends on libxentoolcore.
>
> In xen-4.11.1 with qemu-2.11.2 vfb ob
flight 132538 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132538/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 132511 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132511/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 132469
test-armhf-armhf-libvirt-raw 13 saveresto
On Mon, Jan 28, 2019 at 02:50:00PM +, Wei Liu wrote:
> On Sat, Jan 26, 2019 at 03:31:15AM +0100, Marek Marczykowski-Górecki wrote:
> > From: Simon Gaiser
> >
> > Stubdomains need to be given sufficient privilege over the guest which it
> > provides emulation for in order for PCI passthrough t
flight 132527 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132527/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd broken
build-amd64-freebs
On Mon, Jan 28, 2019 at 02:41:15PM +, Wei Liu wrote:
> On Sat, Jan 26, 2019 at 03:31:14AM +0100, Marek Marczykowski-Górecki wrote:
> > Stubdomain do not have it's own config file - its configuration is
> > derived from target domains. Do not try to manipulate it when attaching
> > PCI device.
>
On 1/28/19 3:29 AM, Oleksandr Andrushchenko wrote:
> +Boris and Juergen who can also help getting it in
I can put this in but I'd like to have Stefano's ack, this being ARM.
-boris
>
> On 1/28/19 8:34 AM, Souptick Joarder wrote:
>> On Mon, Jan 14, 2019 at 4:08 PM Oleksandr Andrushchenko
>> wro
flight 132504 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132504/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16
guest-localmigrate/x10 fail REGR. vs. 13
Access to QMP of QEMU in Linux stubdomain is possible over vchan
connection. Add appropriate handling to synchronous API.
Since only one client can be connected to vchan server at the same time
and it is not enforced by the libxenvchan itself, additional client-side
locking is needed. Note that qem
From: Eric Shelton
This patch creates an appropriate command line for the QEMU instance
running in a Linux-based stubdomain.
NOTE: a number of items are not currently implemented for Linux-based
stubdomains, such as:
- save/restore
- QMP socket
- graphics output (e.g., VNC)
Signed-off-by: Eric
Let the server know when the client is connected. Otherwise server will
notice only when client send some data.
This change does not break existing clients, as libvchan user should
handle spurious notifications anyway (for example acknowledge of remote
side reading the data).
Signed-off-by: Marek
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Jason Andryuk
---
docs/man/xl.cfg.5.pod.in | 23 +++
tools/xl/xl_parse.c | 7 +++
2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 3b92f39
It will be needed for qmp_ev_* over vchan.
No functional change.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v3:
- new patch
---
tools/libxl/libxl_internal.h | 108 ++--
1 file changed, 54 insertions(+), 54 deletions(-)
diff --git a/tools/libxl/li
libxenvchan.h include xenevtchn.h and xengnttab.h, so applications built
with it needs applicable -I in CFLAGS too.
Signed-off-by: Marek Marczykowski-Górecki
---
tools/Rules.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/Rules.mk b/tools/Rules.mk
index 12b3129..a7c6
1 - 100 of 124 matches
Mail list logo
