ic: swapper/1/0/0x0002
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 8/27/21 8:32 AM, Juergen Gross wrote:
> +static bool balloon_thread_cond(enum bp_state state, long credit)
> +{
> + if (state != BP_EAGAIN)
> + credit = 0;
> +
> + return current_credit() != credit || kthread_should_stop();
> +}
> +
> +/*
> + * As this is a kthread it is gu
oc_init+0x36/0x36
> [1.333404] do_one_initcall+0x3e/0x200
> [1.333404] kernel_init_freeable+0x232/0x28e
> [1.333404] ? rest_init+0xd0/0xd0
> [1.333404] kernel_init+0x16/0x120
> [1.333404] ret_from_fork+0x1f/0x30
>
> Cc:
> Signed-off-by: Juergen Gross
Fixes: 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs") ?
Reviewed-by: Boris Ostrovsky
On 9/8/21 11:11 AM, Juergen Gross wrote:
> On 08.09.21 16:47, Boris Ostrovsky wrote:
>>
>>
>> Given that wait_event_interruptible_timeout() is a bunch of nested macros do
>> we need to worry here about overly aggressive compiler optimizing out
>> 'credit
On 9/16/21 11:04 AM, Jan Beulich wrote:
> {
> const struct desc_ptr *desc = this_cpu_ptr(&idt_desc);
> + unsigned i, count = (desc->size + 1) / sizeof(gate_desc);
>
> - xen_convert_trap_info(desc, traps);
Can you instead add a boolean parameter to xen_convert_trap_info() to ind
On 9/16/21 11:05 AM, Jan Beulich wrote:
> Just after having obtained the pointer from kzalloc() there's no reason
> at all to set part of the area to all zero yet another time. Similarly
> there's no point explicitly clearing "ldt_ents".
>
> Signed-off-by
On 9/17/21 3:24 AM, Juergen Gross wrote:
> On 17.09.21 08:50, Jan Beulich wrote:
>> On 17.09.2021 08:47, Juergen Gross wrote:
>>> On 17.09.21 08:40, Jan Beulich wrote:
>>>> On 17.09.2021 03:34, Boris Ostrovsky wrote:
>>>>>
the issue
> in 5.14; the commit named below is the one which actually introduced the
> bad code.)
>
> Fixes: f87e4cac4f4e ("xen: SMP guest support")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jan Beulich
Reviewed-by: Boris Ostrovsky
e_timeout(), causing a system suspend to fail.
>
> Fixes: 8480ed9c2bbd56 ("xen/balloon: use a kernel thread instead a workqueue")
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 9/22/21 6:17 AM, Jan Beulich wrote:
> @@ -817,7 +818,7 @@ static long privcmd_ioctl_mmap_resource(
> unsigned int i;
>
> for (i = 0; i < num; i++) {
> - rc = pfns[i];
> + rc = errs[i];
>
On 9/22/21 9:39 AM, Jan Beulich wrote:
> On 22.09.2021 15:29, Boris Ostrovsky wrote:
>> On 9/22/21 6:17 AM, Jan Beulich wrote:
>>> @@ -817,7 +818,7 @@ static long privcmd_ioctl_mmap_resource(
>>> unsigned int i;
>>>
>>&g
eter is retained there despite now remaining unused
> (and the only caller passing NULL); correct a respective comment as
> well.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Boris Ostrovsky
i.e. no callback == !guest.
>
> Suggested-by: Peter Zijlstra (Intel)
> Originally-by: Peter Zijlstra (Intel)
> Signed-off-by: Like Xu
> Signed-off-by: Zhu Lingshan
> [sean: extracted from static_call patch, fixed get_ip() bug, wrote changelog]
> Signed-off-by: Sean Christopherson
For Xen bits
Reviewed-by: Boris Ostrovsky
On 9/22/21 6:31 AM, Juergen Gross wrote:
>
> - if (xen_have_vcpu_info_placement) {
> - vcpup = &per_cpu(xen_vcpu_info, cpu);
> - info.mfn = arbitrary_virt_to_mfn(vcpup);
> - info.offset = offset_in_page(vcpup);
> + vcpup = &per_cpu(xen_vcpu_info, cpu)
On 9/22/21 6:31 AM, Juergen Gross wrote:
> The initial pvops functions handling irq flags will only ever be called
> before interrupts are being enabled.
>
> So make the __init and switch them to be dummy functions:
What are you making __init?
>
> +/* stub always return ing 0. */
"always
. None of those should ever happen.
>
That last sentence -- famous last words ;-) But yes, sure.
Assuming both patches adjust their commit messages and the typo
Reviewed-by: Boris Ostrovsky
On 9/28/21 2:22 PM, David Hildenbrand wrote:
> Let's simplify return handling.
>
> Signed-off-by: David Hildenbrand
> ---
> arch/x86/xen/mmu_hvm.c | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/xen/mmu_hvm.c b/arch/x86/xen/mmu_hvm.c
> index b242d1f
On 9/28/21 2:22 PM, David Hildenbrand wrote:
> The callback is only used for the vmcore nowadays.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Boris Ostrovsky
On 9/29/21 5:03 AM, David Hildenbrand wrote:
> On 29.09.21 10:45, David Hildenbrand wrote:
>>>
>> Can we go one step further and do
>>
>>
>> @@ -20,24 +20,11 @@ static int xen_oldmem_pfn_is_ram(unsigned long pfn)
>> struct xen_hvm_get_mem_type a = {
>> .domid = DOMID_S
gt; 5: there's no highmem anymore in PV mode
> 6: restrict PV Dom0 identity mapping
For the series:
Reviewed-by: Boris Ostrovsky
>
> Changes are:
> - adapt to Linux kernel style guide
> - use Xen namespace
> - add lots of comments
> - don't use kernel internal defines
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 10/5/21 8:14 AM, David Hildenbrand wrote:
> Let's simplify return handling.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Boris Ostrovsky
kernel.org/r/3b935aa0-6d85-0bcd-100e-15098add3...@oracle.com
>
> Suggested-by: Boris Ostrovsky
> Signed-off-by: David Hildenbrand
Reviewed-by: Boris Ostrovsky
case.
>
> Cc: sta...@vger.kernel.org
> Fixes: 8480ed9c2bbd56 ("xen/balloon: use a kernel thread instead a workqueue")
> Reported-by: Marek Marczykowski-Górecki
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 10/6/21 2:19 AM, Juergen Gross wrote:
> xen_pvh_init() is lacking a prototype in a header, add it.
>
> Reported-by: kernel test robot
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 10/12/21 3:24 AM, Dongli Zhang wrote:
The sched_clock() can be used very early since upstream
commit 857baa87b642 ("sched/clock: Enable sched clock early"). In addition,
with upstream commit 38669ba205d1 ("x86/xen/time: Output xen sched_clock
time from 0"), kdump kernel in Xen HVM guest may
;.
Some files still contain the MIT license text. Replace that by the
related SPDX line.
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
a per-CPU trampoline stack for IDT
entries")
Cc: Jan Beulich
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Peter Anvin
Cc: xen-devel@lists.xenproject.org>
Cc: Boris Ostrovsky
Signed-off-by: Lai Jiangshan
Reviewed-by: Boris Ostrovsky
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
On 9/26/22 10:18 AM, Juergen Gross wrote:
bool pmu_msr_read(unsigned int msr, uint64_t *val, int *err)
{
if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) {
- if (is_amd_pmu_msr(msr)) {
- if (!xen_amd_pmu_emulate(msr, val, 1))
-
On 10/4/22 4:43 AM, Juergen Gross wrote:
bool pmu_msr_read(unsigned int msr, uint64_t *val, int *err)
{
- if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) {
- if (is_amd_pmu_msr(msr)) {
- if (!xen_amd_pmu_emulate(msr, val, 1))
-
() (Oleksandr Tyshchenko)
- add xen_virtio_restricted_mem_acc() stub (Oleksandr Tyshchenko)
Reviewed-by: Oleksandr Tyshchenko #
common code
Reviewed-by: Boris Ostrovsky
On 10/20/22 9:34 AM, Juergen Gross wrote:
On 20.10.22 15:16, Jan Beulich wrote:
On 20.10.2022 13:37, Juergen Gross wrote:
Commit 8714f7bcd3c2 ("xen/pv: add fault recovery control to pmu msr
accesses") introduced code resulting in a warning issued by the smatch
static checker, claiming to use
is available
at [1].
[1]:
https://lore.kernel.org/all/cover.1667336095.git.christophe.jail...@wanadoo.fr/
Reviewed-by: Boris Ostrovsky
_put_map UNMAP_NOTIFY_SEND_EVENT map->notify.event 6
libxenvchan_is_open cli_live 0
Cc: sta...@vger.kernel.org
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Boris Ostrovsky
On 12/10/21 4:28 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
While working with Xen's libxenvchan library I have faced an issue with
unmap notifications sent in wrong order if both UNMAP_NOTIFY_SEND_EVENT
and UNMAP_NOTIFY_CLEAR_BYTE were requested: first we send an event
On 12/16/21 5:02 PM, Oleksandr wrote:
On 09.12.21 22:05, Oleksandr Tyshchenko wrote:
Hello Juergen, Boris
May I please ask, are you happy (or otherwise) with current patch series (I
assume, especially with commits #3-4)?
I think I mentioned last time, in patch 4:
+ if (target_r
On 12/16/21 5:02 PM, Oleksandr wrote:
On 09.12.21 22:05, Oleksandr Tyshchenko wrote:
Hello Juergen, Boris
May I please ask, are you happy (or otherwise) with current patch series (I
assume, especially with commits #3-4)?
LGTM, I have no more comments.
-boris
On 12/17/21 2:19 PM, Oleksandr wrote:
On 17.12.21 21:13, Boris Ostrovsky wrote:
Hi Boris
On 12/16/21 5:02 PM, Oleksandr wrote:
On 09.12.21 22:05, Oleksandr Tyshchenko wrote:
Hello Juergen, Boris
May I please ask, are you happy (or otherwise) with current patch series (I
assume
On 1/4/22 3:46 AM, Jan Beulich wrote:
The hypervisor has been supplying this information for a couple of major
releases. Make use of it. The need to set a flag in the capabilities
field also points out that the prior setting of that field from the
hypervisor interface's gbl_caps one was wrong,
On 1/4/22 11:54 AM, Jan Beulich wrote:
On 04.01.2022 17:50, Boris Ostrovsky wrote:
On 1/4/22 3:46 AM, Jan Beulich wrote:
The hypervisor has been supplying this information for a couple of major
releases. Make use of it. The need to set a flag in the capabilities
field also points out that
On 1/5/22 2:59 AM, Jan Beulich wrote:
Anyway - I'd appreciate if the patch at hand could be taken
independent of possible further adjustments here, as it addresses
an issue observed in the field.
Reviewed-by: Boris Ostrovsky
On 1/20/22 10:25 AM, Roger Pau Monne wrote:
There's no point in disabling x2APIC mode when running as a Xen HVM
guest, just enable it when available.
Signed-off-by: Roger Pau Monné
---
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molna
per around
x2apic_supported.
Signed-off-by: Roger Pau Monné
Reviewed-by: Boris Ostrovsky
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
Due to time constraints I am stepping down as maintainter. I will stay
as reviewer for x86 code (for which create a separate category).
Stefano is now maintainer for Xen hypervisor interface and Oleksandr has
graciously agreed to become a reviewer.
Signed-off-by: Boris Ostrovsky
an be replaced with memunmap().
Reported-by: kernel test robot
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
nts for x86 side here?
Reviewed-by: Boris Ostrovsky
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 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 3/9/22 1:18 AM, Christoph Hellwig wrote:
On Tue, Mar 08, 2022 at 04:38:21PM -0500, Boris Ostrovsky wrote:
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
On 2/27/22 10:15 PM, Qing Wang wrote:
From: Wang Qing
Use the helper function time_is_{before,after}_jiffies() to improve
code readability.
Signed-off-by: Wang Qing
Reviewed-by: Boris Ostrovsky
Applied to for-linus-5.18
ter the 'vcpu_info' for boot vcpu is
registered when the boot vcpu is >= 32.
This issue can be reproduced on purpose via below command at the guest
side when kdump/kexec is enabled:
"taskset -c 33 echo c > /proc/sysrq-trigger"
The bugfix for PVM is not implemented
On 3/5/22 8:38 AM, zhanglianjie wrote:
Use helper macro __ATTR_RW to define HYPERVISOR_ATTR_RW to make code more clear.
Minor readability improvement.
Signed-off-by: zhanglianjie
Reviewed-by: Boris Ostrovsky
Applied to for-linus-5.18 (with whitespace change noted in commit message)
: Boris Ostrovsky
Applied to for-linus-5.18
On 3/14/22 3:31 AM, Christoph Hellwig wrote:
-void __init swiotlb_init(bool addressing_limit, unsigned int flags)
+void __init swiotlb_init_remap(bool addressing_limit, unsigned int flags,
+ int (*remap)(void *tlb, unsigned long nslabs))
{
- size_t bytes = PAGE_ALIGN(defau
On 3/14/22 3:31 AM, Christoph Hellwig wrote:
-
static void __init pci_xen_swiotlb_init(void)
{
if (!xen_initial_domain() && !x86_swiotlb_enable)
return;
x86_swiotlb_enable = true;
- xen_swiotlb = true;
- xen_swiotlb_init_early();
+ swiotlb_i
On 3/14/22 3:31 AM, Christoph Hellwig wrote:
@@ -314,6 +293,7 @@ void __init swiotlb_init(bool addressing_limit, unsigned
int flags)
int swiotlb_init_late(size_t size, gfp_t gfp_mask,
int (*remap)(void *tlb, unsigned long nslabs))
{
+ struct io_tlb_mem *mem = &io_tlb_
On 3/11/22 5:34 AM, Juergen Gross wrote:
All grant table operations related to the "transfer" functionality
are unused currently. There have been users in the old days of the
"Xen-o-Linux" kernel, but those didn't make it upstream.
So remove the "transfer" related functions.
Do we need to a
On 3/15/22 2:36 AM, Christoph Hellwig wrote:
@@ -271,12 +273,23 @@ void __init swiotlb_init(bool addressing_limit, unsigned
int flags)
* allow to pick a location everywhere for hypervisors with guest
* memory encryption.
*/
+retry:
+ bytes = PAGE_ALIGN(defaul
On 3/15/22 2:10 AM, Juergen Gross wrote:
On 15.03.22 00:37, Boris Ostrovsky wrote:
On 3/11/22 5:34 AM, Juergen Gross wrote:
All grant table operations related to the "transfer" functionality
are unused currently. There have been users in the old days of the
"Xen-o-Linux&quo
On 3/11/22 5:34 AM, Juergen Gross wrote:
All grant table operations related to the "transfer" functionality
are unused currently. There have been users in the old days of the
"Xen-o-Linux" kernel, but those didn't make it upstream.
So remove the "transfer" related functions.
Signed-off-by: Ju
On 3/14/22 3:05 AM, jianchunfu wrote:
In the function xen_apic_read(), the initialized value of 'ret' is unused
because it will be assigned by the function HYPERVISOR_platform_op(),
thus remove it.
Signed-off-by: jianchunfu
Reviewed-by: Boris Ostrovsky
Applied to for-linus-
On 3/22/22 11:50 AM, Juergen Gross wrote:
is_xen_pmu() is taking the cpu number as parameter, but it is not using
it. Instead it just tests whether the Xen PMU initialization on the
current cpu did succeed. As this test is done by checking a percpu
pointer, preemption needs to be disabled in or
boolean variable not being set.
Fixes: bf6dfb154d93 ("xen/PMU: PMU emulation code")
Reported-by: Marek Marczykowski-Górecki
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 3/22/22 9:21 PM, Jakub Kądziołka wrote:
If a xen domain with at least two VCPUs has a PCI device attached which
enters the D3hot state during suspend, the kernel may hang while
resuming, depending on the core on which an async resume task gets
scheduled.
The bug occurs because xen's do_susp
On 3/25/22 10:20 AM, Juergen Gross wrote:
is_xen_pmu() is taking the cpu number as parameter, but it is not using
it. Instead it just tests whether the Xen PMU initialization on the
current cpu did succeed. As this test is done by checking a percpu
pointer, preemption needs to be disabled in or
://git.infradead.org/users/hch/misc.git swiotlb-init-cleanup
Gitweb:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/swiotlb-init-cleanup
Tested-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
1 - 100 of 1148 matches
Mail list logo
