On 11/24/21 5:54 PM, Thomas Gleixner wrote:
On Mon, Nov 22 2021 at 16:47, Sebastian Andrzej Siewior wrote:
From: "Longpeng(Mike)"
A CPU will not show up in virtualized environment which includes an
Enclave. The VM splits its resources into a primary VM and a Enclave
VM. While the Enclave is
On 11/23/21 4:07 PM, Stefano Stabellini wrote:
From: Stefano Stabellini
If the xenstore page hasn't been allocated properly, reading the value
of the related hvm_param (HVM_PARAM_STORE_PFN) won't actually return
error. Instead, it will succeed and return zero. Instead of attempting
to xen_rem
On 11/22/21 3:20 AM, Juergen Gross wrote:
On 22.10.21 08:47, Juergen Gross wrote:
Today the non-essential pv devices are hard coded in the xenbus driver
and this list is lacking multiple entries.
This series reworks the detection logic of non-essential devices by
adding a flag for that purpos
On 11/25/21 4:20 AM, Juergen Gross wrote:
Juergen Gross (2):
xen: make HYPERVISOR_get_debugreg() always_inline
xen: make HYPERVISOR_set_debugreg() always_inline
arch/x86/include/asm/xen/hypercall.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Boris
ed altogether, while
xen_filter_cpu_maps() is re-purposed but not otherwise changed.
Signed-off-by: Jan Beulich
---
v2: Extend description.
That's been a while ;-)
Reviewed-by: Boris Ostrovsky
On 2/22/22 10:35 AM, Christoph Hellwig wrote:
Hi all,
this series tries to clean up the swiotlb initialization, including
that of swiotlb-xen. To get there is also removes the x86 iommu table
infrastructure that massively obsfucates the initialization path.
Git tree:
git://git.infradea
, Feb 23, 2022 at 07:57:49PM -0500, Boris Ostrovsky wrote:
[ 37.377313] BUG: unable to handle page fault for address: c90042880018
[ 37.378219] #PF: supervisor read access in kernel mode
[ 37.378219] #PF: error_code(0x) - not-present page
[ 37.378219] PGD 7c2f2ee067 P4D 7c2f2ee06
On 2/24/22 11:39 AM, Christoph Hellwig wrote:
On Thu, Feb 24, 2022 at 11:18:33AM -0500, Boris Ostrovsky wrote:
On 2/24/22 10:58 AM, Christoph Hellwig wrote:
Thanks.
This looks really strange as early_amd_iommu_init should not interact much
with the changes. I'll see if I can find
On 2/25/22 3:47 AM, Christoph Hellwig wrote:
On Thu, Feb 24, 2022 at 12:07:26PM -0500, Boris Ostrovsky wrote:
Just to be clear: this crashes only as dom0. Boots fine as baremetal.
Ah. I can gues what this might be. On Xen the hypervisor controls the
IOMMU and we should never end up
[0.00] ? secondary_startup_64_no_verify+0xd5/0xdb
[0.00]
Changed since v1:
- Add commit message to explain why xen_hvm_init_time_ops() is delayed
for any vcpus. (Suggested by Boris Ostrovsky)
- Add a comment in xen_hvm_smp_prepare_boot_cpu() referencing the related
code in xen_h
On 2/25/22 8:17 PM, Dongli Zhang wrote:
Hi Boris,
On 2/25/22 2:39 PM, Boris Ostrovsky wrote:
On 2/24/22 4:50 PM, Dongli Zhang wrote:
This is the v3 of the patch to fix xen kexec kernel panic issue when the
kexec is triggered on VCPU >= 32.
PANIC: early exception 0x0e IP
On 2/28/22 11:56 PM, Dongli Zhang wrote:
Hi Boris,
On 2/28/22 5:18 PM, Dongli Zhang wrote:
Hi Boris,
On 2/28/22 12:45 PM, Boris Ostrovsky wrote:
On 2/25/22 8:17 PM, Dongli Zhang wrote:
Hi Boris,
On 2/25/22 2:39 PM, Boris Ostrovsky wrote:
On 2/24/22 4:50 PM, Dongli Zhang wrote:
This is
On 3/1/22 9:55 PM, Stefano Stabellini wrote:
On Tue, 1 Mar 2022, Christoph Hellwig wrote:
Allow to pass a remap argument to the swiotlb initialization functions
to handle the Xen/x86 remap case. ARM/ARM64 never did any remapping
from xen_swiotlb_fixup, so we don't even need that quirk.
A
On 3/2/22 8:15 AM, Boris Ostrovsky wrote:
On 3/1/22 9:55 PM, Stefano Stabellini wrote:
On Tue, 1 Mar 2022, Christoph Hellwig wrote:
Allow to pass a remap argument to the swiotlb initialization functions
to handle the Xen/x86 remap case. ARM/ARM64 never did any remapping
from
On 3/2/22 11:40 AM, Dongli Zhang wrote:
void __init xen_hvm_init_time_ops(void)
{
+ static bool hvm_time_initialized;
+
+ if (hvm_time_initialized)
+ return;
+
/*
* vector callback is needed otherwise we cannot receive interrupts
* on cpu
On 3/2/22 7:31 PM, Dongli Zhang wrote:
Hi Boris,
On 3/2/22 4:20 PM, Boris Ostrovsky wrote:
On 3/2/22 11:40 AM, Dongli Zhang wrote:
void __init xen_hvm_init_time_ops(void)
{
+ static bool hvm_time_initialized;
+
+ if (hvm_time_initialized)
+ return
On 3/3/22 5:57 AM, Christoph Hellwig wrote:
On Wed, Mar 02, 2022 at 08:15:03AM -0500, Boris Ostrovsky wrote:
Not for me, I fail to boot with
[ 52.202000] bnxt_en :31:00.0: swiotlb buffer is full (sz: 256 bytes),
total 0 (slots), used 0 (slots)
(this is iscsi root so I need the NIC
On 3/4/22 12:28 PM, Christoph Hellwig wrote:
On Wed, Mar 02, 2022 at 08:15:03AM -0500, Boris Ostrovsky wrote:
Not for me, I fail to boot with
[ 52.202000] bnxt_en :31:00.0: swiotlb buffer is full (sz: 256 bytes),
total 0 (slots), used 0 (slots)
(this is iscsi root so I need the NIC
On 3/4/22 12:43 PM, Christoph Hellwig wrote:
On Fri, Mar 04, 2022 at 12:36:17PM -0500, Boris Ostrovsky wrote:
I bisected it to "x86: remove the IOMMU table infrastructure" but haven't
actually looked at the code yet.
That looks like the swiotlb buffer did not get initialize
On 3/1/22 5:53 AM, Christoph Hellwig wrote:
Allow to pass a remap argument to the swiotlb initialization functions
to handle the Xen/x86 remap case. ARM/ARM64 never did any remapping
from xen_swiotlb_fixup, so we don't even need that quirk.
Any chance this patch could be split? Lots of thin
On 9/16/22 8:52 AM, Jan Beulich wrote:
On 15.09.2022 16:01, Tamas K Lengyel wrote:
While experimenting with the vPMU subsystem an ASSERT failure was
observed in vmx_find_msr because the vcpu_runnable state was true.
The root cause of the bug appears to be the fact that the vPMU subsystem
does
, Sep 19, 2022 at 5:28 AM Jan Beulich wrote:
On 16.09.2022 23:35, Boris Ostrovsky wrote:
On 9/16/22 8:52 AM, Jan Beulich wrote:
On 15.09.2022 16:01, Tamas K Lengyel wrote:
While experimenting with the vPMU subsystem an ASSERT failure was
observed in vmx_find_msr because the vcpu_runnable state
On 9/20/22 4:01 AM, Jan Beulich wrote:
On 20.09.2022 00:42, Boris Ostrovsky wrote:
It is saving vpmu data from current pcpu's MSRs for a remote vcpu so @v
in vmx_find_msr() is not @current:
vpmu_load()
...
prev = per_cpu(last_vcpu,
On 9/20/22 10:54 AM, Jan Beulich wrote:
On 20.09.2022 16:26, Boris Ostrovsky wrote:
On 9/20/22 4:01 AM, Jan Beulich wrote:
On 20.09.2022 00:42, Boris Ostrovsky wrote:
It is saving vpmu data from current pcpu's MSRs for a remote vcpu so @v
in vmx_find_msr() is not @cu
te-warning]
__write_overflow_field(p_size_field, size);
^
which was isolated to the memset() call in xen_load_idt().
Note that this looks very much like another bug that was worked around:
https://github.com/ClangBuiltLinux/linux/issues/1592
Cc: Juergen Gross
Cc: Boris
_play_dead() return
x86/xen: mark xen_pv_play_dead() as __noreturn
arch/x86/xen/smp.h | 2 ++
arch/x86/xen/smp_pv.c | 17 -
arch/x86/xen/xen-head.S | 7 +++
tools/objtool/check.c | 1 +
4 files changed, 14 insertions(+), 13 deletions(-)
Ping?
Reviewed
On 2/13/23 11:41 AM, Jan Beulich wrote:
On 13.02.2023 17:30, Xenia Ragiadakou wrote:
On 2/13/23 17:11, Jan Beulich wrote:
On 13.02.2023 15:57, Xenia Ragiadakou wrote:
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -10,4 +10,6 @@ obj-y += intel.o
obj-y += intel_cacheinf
On 2/14/23 2:48 AM, Jan Beulich wrote:
On 13.02.2023 21:53, Boris Ostrovsky wrote:
On 2/13/23 11:41 AM, Jan Beulich wrote:
On 13.02.2023 17:30, Xenia Ragiadakou wrote:
On 2/13/23 17:11, Jan Beulich wrote:
On 13.02.2023 15:57, Xenia Ragiadakou wrote:
--- a/xen/arch/x86/cpu/Makefile
+++ b
On 2/14/23 11:13 AM, Jan Beulich wrote:
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -18,6 +18,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -32,6 +34,7 @@
#include
#include
#include
+#include
#include
#include "c
On 2/14/23 6:53 PM, Boris Ostrovsky wrote:
On 2/14/23 11:13 AM, Jan Beulich wrote:
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -18,6 +18,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -32,6 +34,7 @@
#include
#include
On 2/15/23 3:31 AM, Jan Beulich wrote:
On 15.02.2023 01:07, Boris Ostrovsky wrote:
On 2/14/23 6:53 PM, Boris Ostrovsky wrote:
On 2/14/23 11:13 AM, Jan Beulich wrote:
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -18,6 +18,8 @@
#include
#include
+#include
On 2/23/23 4:32 AM, Juergen Gross wrote:
+
+ for (reg = 0; reg < MTRR_MAX_VAR_RANGES; reg++) {
+ op.u.read_memtype.reg = reg;
+ if (HYPERVISOR_platform_op(&op))
+ break;
If we fail on the first iteration, do we still want to mark MTRRs a
On 2/27/23 2:12 AM, Juergen Gross wrote:
On 24.02.23 22:00, Boris Ostrovsky wrote:
On 2/23/23 4:32 AM, Juergen Gross wrote:
+
+ for (reg = 0; reg < MTRR_MAX_VAR_RANGES; reg++) {
+ op.u.read_memtype.reg = reg;
+ if (HYPERVISOR_platform_op(&op))
+ break;
bits as Jan had already reviewed it but in
case you do
Reviewed-by: Boris Ostrovsky
On 6/29/22 4:03 PM, Stefano Stabellini wrote:
Adding Juergen and Boris because this is a Linux/x86 issue.
As you can see from this Linux driver:
https://elixir.bootlin.com/linux/latest/source/drivers/crypto/ccp/tee-dev.c#L132
Linux as dom0 on x86 is trying to communicate with firmware (TEE).
On 7/12/22 12:38 PM, Greg KH wrote:
Hi all,
I'm seeing the following build warning:
arch/x86/kernel/head_64.o: warning: objtool:
xen_hypercall_mmu_update(): can't find starting instruction
in the 5.15.y and 5.10.y retbleed backports.
I don't know why just this one hypercall is being
On 7/12/22 3:31 PM, Greg KH wrote:
On Tue, Jul 12, 2022 at 03:19:39PM -0400, Boris Ostrovsky wrote:
On 7/12/22 12:38 PM, Greg KH wrote:
Hi all,
I'm seeing the following build warning:
arch/x86/kernel/head_64.o: warning: objtool:
xen_hypercall_mmu_update(): can't fin
On 7/11/22 11:22 AM, Jane Malalane wrote:
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include
#include
@@ -30,6 +31,9 @@
static unsigned long shared_info_pfn;
+__ro_after_init bool xen_ack_upcall
On 7/15/22 5:50 AM, Andrew Cooper wrote:
On 15/07/2022 09:18, Jane Malalane wrote:
On 14/07/2022 00:27, Boris Ostrovsky wrote:
xen_hvm_smp_init();
WARN_ON(xen_cpuhp_setup(xen_cpu_up_prepare_hvm, xen_cpu_dead_hvm));
diff --git a/arch/x86/xen/suspend_hvm.c b/arch/x86/xen
d to other stable branches as well.
TL;DR: for this particular warning, objtool would exit early and fail to
create any .orc_unwind* ELF sections for head_64.o, which are consumed
by the ORC unwinder at runtime.
Boris Ostrovsky writes:
On 7/12/22 3:31 PM, Greg KH wrote:
On Tue, Jul 12, 2022 at
On 7/17/22 1:20 AM, Juergen Gross wrote:
What about filling the complete hypercall page just with "int 3" or "ud2"?
Any try to do a hypercall before the hypercall page has been initialized
is a bug anyway. What good can come from calling a function which will
return a basically random value i
On 7/18/22 4:56 AM, Andrew Cooper wrote:
On 15/07/2022 14:10, Boris Ostrovsky wrote:
On 7/15/22 5:50 AM, Andrew Cooper wrote:
On 15/07/2022 09:18, Jane Malalane wrote:
On 14/07/2022 00:27, Boris Ostrovsky wrote:
xen_hvm_smp_init();
WARN_ON(xen_cpuhp_setup
On 7/25/22 6:03 AM, Jane Malalane wrote:
On 18/07/2022 14:59, Boris Ostrovsky wrote:
On 7/18/22 4:56 AM, Andrew Cooper wrote:
On 15/07/2022 14:10, Boris Ostrovsky wrote:
On 7/15/22 5:50 AM, Andrew Cooper wrote:
On 15/07/2022 09:18, Jane Malalane wrote:
On 14/07/2022 00:27, Boris Ostrovsky
On 7/26/22 8:56 AM, Jane Malalane wrote:
+/* Setup per-vCPU vector-type callbacks and trick toolstack to think
+ * we are enlightened. If this setup is unavailable, fallback to the
+ * global vector-type callback. */
Comment style.
+static __init void xen_init_setup_upcall_vector(void)
On 7/28/22 8:52 AM, Jane Malalane wrote:
+/*
+ * Setup per-vCPU vector-type callbacks and trick toolstack to think
The comment should be adjusted -- no need to mention toolstack now that that
code has been factored out.
Other than that
Reviewed-by: Boris Ostrovsky
+ * we are
abled() properly reflect state when
running on Xen")
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
on to complete makes no difference.
Signed-off-by: Thomas Gleixner
Cc: Juergen Gross
Cc: Boris Ostrovsky
Cc: xen-devel@lists.xenproject.org
---
arch/x86/xen/smp_pv.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -3
On 7/15/21 3:39 AM, Roman Skakun wrote:
>> This looks like it wasn't picked up? Should it go in rc1?
> Hi, Konrad!
>
> This looks like an unambiguous bug, and should be in rc1.
Looks like you didn't copy Christoph which could be part of the problem. Adding
him.
-boris
>
> Cheers!
>
> ср,
eturning errors as
> DMA_MAPPING_ERROR. So coalesce all errors into EINVAL.
Reviewed-by: Boris Ostrovsky
On 7/21/21 11:36 AM, Juergen Gross wrote:
> On 21.07.21 13:40, Colin King wrote:
>> From: Colin Ian King
>>
>> The variable irq is being initialized with a value that is never
>> read, it is being updated later on. The assignment is redundant and
>> can be removed.
>>
>> Addresses-Coverity: ("Un
t; drivers/xen/gntdev.c| 36 ++--
> 4 files changed, 24 insertions(+), 46 deletions(-)
Reviewed-by: Boris Ostrovsky
On 7/29/21 4:37 PM, Uwe Kleine-König wrote:
> --- a/drivers/pci/xen-pcifront.c
> +++ b/drivers/pci/xen-pcifront.c
> @@ -599,12 +599,12 @@ static pci_ers_result_t pcifront_common_process(int cmd,
> result = PCI_ERS_RESULT_NONE;
>
> pcidev = pci_get_domain_bus_and_slot(domain, bus, d
On 7/31/21 8:08 AM, Uwe Kleine-König wrote:
> Hello Boris,
>
> On Fri, Jul 30, 2021 at 04:37:31PM -0400, Boris Ostrovsky wrote:
>> On 7/29/21 4:37 PM, Uwe Kleine-König wrote:
>>> --- a/drivers/pci/xen-pcifront.c
>>> +++ b/drivers/pci/xen-pcifront.c
/pci/xen-pcifront.c | 57 +-
> 1 file changed, 25 insertions(+), 32 deletions(-)
Reviewed-by: Boris Ostrovsky
| 7 ++--
> drivers/usb/host/xhci-pci.c | 3 +-
> 21 files changed, 112 insertions(+), 84 deletions(-)
For Xen bits:
Reviewed-by: Boris Ostrovsky
On 8/6/21 7:06 AM, Colin King wrote:
> From: Colin Ian King
>
> The variable err is being assigned a value that is never read, the
> assignment is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
Reviewed-by: Boris Ostrovsky
leine-König
Xen:
Reviewed-by: Boris Ostrovsky
On 8/11/21 10:08 AM, Maximilian Heyne wrote:
>
> This patch sets evtchn_to_irq rows via a cmpxchg operation so that they
> will be set only once. Clearing the row was moved up before writing the
> row to evtchn_to_irq in order to not create a race once the row is
> visible for other threads. Acce
efore writing it to
> evtchn_to_irq in order to not create a race once the row is visible for
> other threads.
>
> While at it, do not require the page to be zeroed, because it will be
> overwritten with -1's in clear_evtchn_to_irq_row anyway.
>
> Signed-off-by: Maximilian Heyne
> Fixes: d0b075ffeede ("xen/events: Refactor evtchn_to_irq array to be
> dynamically allocated")
Reviewed-by: Boris Ostrovsky
On 11/29/22 10:00 AM, Per Bilse wrote:
+static ssize_t flags_show(struct hyp_sysfs_attr *attr, char *buffer)
+{
+ static char const *const sifstr[SIFN_NUM_SIFN] = {
+ [SIFN_PRIV] = "privileged",
+ [SIFN_INIT] = "initdomain",
+ [SIFN_MULTI] =
On 12/8/22 11:36 AM, Krister Johansen wrote:
+ /*
+* As Dom0 is never moved, no penalty on using TSC there.
+*
+* If the guest has invariant tsc, then set xen_clocksource rating
+* below that of the tsc so that the system prefers tsc instead. This
+
On 12/12/22 11:05 AM, Krister Johansen wrote:
diff --git a/arch/x86/include/asm/xen/cpuid.h b/arch/x86/include/asm/xen/cpuid.h
index 6daa9b0c8d11..d9d7432481e9 100644
--- a/arch/x86/include/asm/xen/cpuid.h
+++ b/arch/x86/include/asm/xen/cpuid.h
@@ -88,6 +88,12 @@
* EDX: shift am
On 12/12/22 5:09 PM, Krister Johansen wrote:
On Mon, Dec 12, 2022 at 01:48:24PM -0500, Boris Ostrovsky wrote:
On 12/12/22 11:05 AM, Krister Johansen wrote:
diff --git a/arch/x86/include/asm/xen/cpuid.h b/arch/x86/include/asm/xen/cpuid.h
index 6daa9b0c8d11..d9d7432481e9 100644
--- a/arch/x86
On 12/14/22 1:01 PM, Krister Johansen wrote:
On Tue, Dec 13, 2022 at 04:25:32PM -0500, Boris Ostrovsky wrote:
On 12/12/22 5:09 PM, Krister Johansen wrote:
On Mon, Dec 12, 2022 at 01:48:24PM -0500, Boris Ostrovsky wrote:
On 12/12/22 11:05 AM, Krister Johansen wrote:
diff --git a/arch/x86
callback .mmu.enter_mmap (in contrast to the
corresponding already existing .mmu.exit_mmap).
As the first parameter of the old callbacks isn't used, drop it from
the replacement one.
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 4/22/21 11:10 AM, Juergen Gross wrote:
>
> +/*
> + * Linux kernel expects at least Xen 4.0.
> + *
> + * Assume some features to be available for that reason (depending on guest
> + * mode, of course).
> + */
> +#define chk_feature(f) { \
> +
gt; + printk(KERN_WARNING "Xen-SWIOTLB: swiotlb buffer already
> initialized\n");
pr_warn().
Reviewed-by: Boris Ostrovsky
On 5/11/21 8:18 PM, Connor Davis wrote:
> Export xen_dbgp_reset_prep and xen_dbgp_external_startup
> when CONFIG_XEN_DOM0 is defined. This allows use of these symbols
> even if CONFIG_EARLY_PRINK_DBGP is defined.
>
> Signed-off-by: Connor Davis
> ---
> drivers/xen/dbgp.c | 2 +-
Unrelated to y
On 5/12/21 10:58 AM, Connor Davis wrote:
> On May 12, 21, Boris Ostrovsky wrote:
>> Unrelated to your patch but since you are fixing things around that file ---
>> should we return -EPERM in xen_dbgp_op() when !xen_initial_domain()?
> Yeah looks like it. That would make p
t;
> Also invert the return values from dbgp_external_startup for
> consistency with dbgp_reset_prep (this inversion has no functional
> change since no callers actually check the value).
>
> Signed-off-by: Connor Davis
For Xen bits:
Reviewed-by: Boris Ostrovsky
For the rest it see
On 5/18/21 12:13 PM, Jan Beulich wrote:
>
> @@ -95,22 +95,25 @@ static int __xen_pcibk_add_pci_dev(struc
>
> /*
>* Keep multi-function devices together on the virtual PCI bus, except
> - * virtual functions.
> + * that we want to keep virtual functions at func 0 on the
Bus state to Initialised, at which point no further
> reconfigures would happen unless a device got hotplugged. Arrange for
> reconfigure to also get triggered from the backend watch handler.
>
> Signed-off-by: Jan Beulich
> Cc: sta...@vger.kernel.org
Reviewed-by: Boris Ostrovsky
On 5/20/21 3:43 AM, Jan Beulich wrote:
> On 20.05.2021 02:36, Boris Ostrovsky wrote:
>> On 5/18/21 12:13 PM, Jan Beulich wrote:
>>>
>>> @@ -95,22 +95,25 @@ static int __xen_pcibk_add_pci_dev(struc
>>>
>>> /*
>>> * Keep multi-fu
On 5/20/21 10:46 AM, Jan Beulich wrote:
> On 20.05.2021 16:44, Jan Beulich wrote:
>> On 20.05.2021 16:38, Boris Ostrovsky wrote:
>>> On 5/20/21 3:43 AM, Jan Beulich wrote:
>>>> On 20.05.2021 02:36, Boris Ostrovsky wrote:
>>>>> On 5/18/21 12:13 PM,
On 5/21/21 3:45 AM, Juergen Gross wrote:
> On 21.05.21 09:26, Jan Beulich wrote:
>> On 21.05.2021 09:18, Juergen Gross wrote:
>>> On 20.05.21 14:08, Jan Beulich wrote:
On 20.05.2021 13:57, Juergen Gross wrote:
> On 20.05.21 13:42, Jan Beulich wrote:
>> xen_setup_gdt(), via xen_load_g
On 5/21/21 9:15 AM, Jan Beulich wrote:
> On 21.05.2021 15:12, Boris Ostrovsky wrote:
>>
>> Did something changed recently that this became a problem? That commit has
>> been there for 3 years.
> He happened to try on a system where NX was turned off in the BIOS.
On 5/23/21 3:02 AM, YueHaibing wrote:
> Use DEVICE_ATTR_RW helper instead of plain DEVICE_ATTR,
> which makes the code a bit shorter and easier to read.
>
> Signed-off-by: YueHaibing
Do you think you can also make similar change in drivers/xen/xen-balloon.c and
drivers/xen/xenbus/xenbus_probe
On 5/21/21 1:26 AM, Anchal Agarwal wrote:
>>> What I meant there wrt VCPU info was that VCPU info is not unregistered
>>> during hibernation,
>>> so Xen still remembers the old physical addresses for the VCPU information,
>>> created by the
>>> booting kernel. But since the hibernation kernel m
On 5/26/21 12:40 AM, Anchal Agarwal wrote:
> On Tue, May 25, 2021 at 06:23:35PM -0400, Boris Ostrovsky wrote:
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you can confirm the sender and know
>>
On 5/26/21 10:10 AM, YueHaibing wrote:
> Use DEVICE_ATTR_*() helper instead of plain DEVICE_ATTR(),
> which makes the code a bit shorter and easier to read.
>
> Signed-off-by: YueHaibing
Reviewed-by: Boris Ostrovsky
On 5/28/21 5:50 PM, Anchal Agarwal wrote:
> That only fails during boot but not after the control jumps into the image.
> The
> non boot cpus are brought offline(freeze_secondary_cpus) and then online via
> cpu hotplug path. In that case xen_vcpu_setup doesn't invokes the hypercall
> again.
On 5/30/21 11:06 AM, Tianyu Lan wrote:
> @@ -91,6 +92,6 @@ int pci_xen_swiotlb_init_late(void)
> EXPORT_SYMBOL_GPL(pci_xen_swiotlb_init_late);
>
> IOMMU_INIT_FINISH(2,
> - NULL,
> + hyperv_swiotlb_detect,
> pci_xen_swiotlb_init,
> NU
On 6/2/21 11:01 AM, Tianyu Lan wrote:
> Hi Boris:
> Thanks for your review.
>
> On 6/2/2021 9:16 AM, Boris Ostrovsky wrote:
>>
>> On 5/30/21 11:06 AM, Tianyu Lan wrote:
>>> @@ -91,6 +92,6 @@ int pci_xen_swiotlb_init_late(void)
>>> E
On 6/3/21 11:37 AM, Tianyu Lan wrote:
>
> Yes, the dependency is between hyperv_swiotlb_detect() and
> pci_swiotlb_detect_override()/pci_swiotlb_detect_4gb(). Now
> pci_swiotlb_detect_override() and pci_swiotlb_detect_4gb() depends on
> pci_xen_swiotlb_detect(). To keep dependency between
> hyper
On 6/2/21 3:37 PM, Anchal Agarwal wrote:
> On Tue, Jun 01, 2021 at 10:18:36AM -0400, Boris Ostrovsky wrote:
>>
> The resume won't fail because in the image the xen_vcpu and xen_vcpu_info are
> same. These are the same values that got in there during saving of the
> hiberna
On 6/3/21 7:27 PM, Anchal Agarwal wrote:
> On Thu, Jun 03, 2021 at 04:11:46PM -0400, Boris Ostrovsky wrote:
>
>> But if KASLR is on then this comparison not failing should cause xen_vcpu
>> pointer in the loaded image to become bogus because xen_vcpu is now
>> re
On 6/11/21 5:55 AM, Roman Skakun wrote:
>
> +static int
> +xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma,
> + void *cpu_addr, dma_addr_t dma_addr, size_t size,
> + unsigned long attrs)
> +{
> + unsigned long user_count = vma_pages(vma);
> +
On 6/14/21 8:47 AM, Roman Skakun wrote:
> Hey, Boris!
> Thanks for the review.
>
> I have an additional question about current implementation that disturbed me.
> I think, that we can have cases when mapped memory can not be
> physically contiguous.
> In order to proceed this correctly need to ap
***
>>>> Since this suggests a timer was found on the list without ever having been
>>>> initialized, I've spotted a case where this indeed could now happen. Could
>>>> you give the patch below a try?
>>>>
>>>> Ja
On 6/16/21 7:42 AM, Roman Skakun wrote:
> This commit is dedicated to fix incorrect conversion from
> cpu_addr to page address in cases when we get virtual
> address which allocated through xen_swiotlb_alloc_coherent()
> and can be mapped in the vmalloc range.
> As the result, virt_to_page() cann
On 6/16/21 10:21 AM, Christoph Hellwig wrote:
> On Wed, Jun 16, 2021 at 10:12:55AM -0400, Boris Ostrovsky wrote:
>> I wonder now whether we could avoid code duplication between here and
>> dma_common_mmap()/dma_common_get_sgtable() and use your helper there.
>>
>>
&g
On 6/16/21 11:35 AM, Christoph Hellwig wrote:
> On Wed, Jun 16, 2021 at 11:33:50AM -0400, Boris Ostrovsky wrote:
>> Isn't the expectation of virt_to_page() that it only works on non-vmalloc'd
>> addresses? (This is not a rhetorical question, I actually don't
xenpmu_data->pmu.r.regs.cpl & 3))
> + state |= PERF_GUEST_USER;
Please drop "!!", it's not needed here. And use "else if".
With that, for Xen bits:
Reviewed-by: Boris Ostrovsky
-boris
not modified as there is no explicit call
> to xen_irq_lateeoi() expected later.
>
> Reported-by: Julien Grall
> Fixes: b6622798bc50b62 ("xen/events: avoid handling the same event on two
> cpus at the same time")
> Tested-by: Julien Grall
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 7/3/24 7:56 AM, Juergen Gross wrote:
#define MC_BATCH 32
-#define MC_DEBUG 0
-
#define MC_ARGS (MC_BATCH * 16)
struct mc_buffer {
unsigned mcidx, argidx, cbidx;
struct multicall_entry entries[MC_BATCH];
-#if MC_DEBUG
- struct multicall
On 7/8/24 5:04 AM, Jürgen Groß wrote:
On 06.07.24 00:36, boris.ostrov...@oracle.com wrote:
Also, would it be better to keep these fields as a struct of scalars
and instead have the percpu array of this struct? Otherwise there is a
whole bunch of [MC_BATCH] arrays, all of them really i
stored in the multicall data for each call
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
/xen/smp.h
Reviewed-by: Boris Ostrovsky
.initdata
section, as it needs to be accessed for cpuhotplug, too.
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
er just on cpu0 may be sufficient. Not sure where to do this though.
But this works as well.
Reviewed-by: Boris Ostrovsky
901 - 1000 of 1149 matches
Mail list logo
