On 9/21/23 14:11, Nikolay Borisov wrote:
+SYM_FUNC_START(asm_fred_entry_from_kvm)
+ push %rbp
+ mov %rsp, %rbp
use FRAME_BEGIN/FRAME_END macros to ommit this code if
CONFIG_FRAME_POINTER is disabled.
No, the previous stack pointer is used below, so the code might as well
use %rbp for
On 9/14/23 06:48, Xin Li wrote:
When FRED is enabled, call fred_entry_from_kvm() to handle IRQ/NMI in
IRQ/NMI induced VM exits.
Tested-by: Shan Kang
Signed-off-by: Xin Li
Acked-by: Paolo Bonzini
---
arch/x86/kvm/vmx/vmx.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions
On 9/14/23 06:48, Xin Li wrote:
+ /*
+* Don't check the FRED stack level, the call stack leading to this
+* helper is effectively constant and shallow (relatively speaking).
It's more that we don't need to protect from reentrancy. The external
interrupt uses stack level
On 22/08/19 16:30, lantianyu1...@gmail.com wrote:
> From: Tianyu Lan
>
> This patchset is to add Hyper-V direct tlb support in KVM. Hyper-V
> in L0 can delegate L1 hypervisor to handle tlb flush request from
> L2 guest when direct tlb flush is enabled in L1.
>
> Patch 2 introduces new cap KVM_CA
On 05/09/19 02:57, Xiaoyao Li wrote:
> Userspace can use ioctl KVM_SET_MSRS to update a set of MSRs of guest.
> This ioctl set specified MSRs one by one. If it fails to set an MSR,
> e.g., due to setting reserved bits, the MSR is not supported/emulated by
> KVM, etc..., it stops processing the MSR
On 14/08/19 15:26, Paolo Bonzini wrote:
> On 14/08/19 09:34, lantianyu1...@gmail.com wrote:
>> From: Tianyu Lan
>>
>> The struct hv_vp_assist_page was defined incorrectly.
>> The "vtl_control" should be u64[3], "nested_enlightenments
>> _contro
On 14/08/19 09:34, lantianyu1...@gmail.com wrote:
> From: Tianyu Lan
>
> The struct hv_vp_assist_page was defined incorrectly.
> The "vtl_control" should be u64[3], "nested_enlightenments
> _control" should be a u64 and there is 7 reserved bytes
> following "enlighten_vmentry". This patch is to f
On 08/07/19 22:20, Jonathan Corbet wrote:
+:Author: Glauber Costa , Red Hat Inc, 2010
>>> I rather suspect that email address doesn't work these days.
>>>
>> No I guess it wont :). We would still keep this correct?
> There's nothing good that will come from keeping a broken email address
On 24/07/19 20:00, Jonathan Corbet wrote:
> - kvm/api.txt pretty clearly belongs in the userspace-api book, rather
>than tossed in with:
>
> - kvm/review-checklist.txt, which belongs in the subsystem guide, if only
>we'd gotten around to creating it yet, or
>
> - kvm/mmu.txt, which is
On 24/07/19 09:24, Christoph Hellwig wrote:
> Renaming docs seems to be en vogue at the moment, so fix on of the
> grossly misnamed directories. We usually never use "virtual" as
> a shortcut for virtualization in the kernel, but always virt,
> as seen in the virt/ top-level directory. Fix up the
+++ b/Documentation/virtual/kvm/index.rst
> @@ -9,3 +9,4 @@ KVM
>
> amd-memory-encryption
> cpuid
> + vcpu-requests
>
Acked-by: Paolo Bonzini
On 09/07/19 22:07, Luke Nowakowski-Krijger wrote:
> After confirming with the appropriate lists that all the
> Documentation/virtual/* files are not obsolete I will continue
> converting the rest of the .txt files to .rst.
There is no obsolete information in Documentation/virtual/kvm. Thanks
for
and [kvm-forum]_ for more info.
> +
> .. [white-paper]
> http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
> .. [api-spec]
> http://support.amd.com/TechDocs/55766_SEV-KM_API_Specification.pdf
> .. [amd-apm] http://support.amd.com/TechDocs/24593.pdf (section 15.34)
>
Acked-by: Paolo Bonzini
On 29/05/19 04:25, Tao Xu wrote:
>>
> OK, but should we just drop this patch?
> Or add the VMX_EXIT_REASONS bits of UMWAIT and TPAUSE and handle like
> XSAVES/XRSTORS:
> "kvm_skip_emulated_instruction(vcpu);"
> "WARN(1, "this should never happen\n");"
Yes, this sounds good to me.
Paolo
On 29/05/19 04:05, Tao Xu wrote:
>>
>
> Thank you Paolo, but I have another question. I was wondering if it is
> appropriate to enable X86_FEATURE_WAITPKG when QEMU uses "-overcommit
> cpu-pm=on"?
"-overcommit" only establishes the behavior of KVM, it doesn't change
the cpuid bits. So you'd need
On 24/05/19 09:56, Tao Xu wrote:
> +
> + if (rdmsrl_safe(MSR_IA32_UMWAIT_CONTROL, &host_umwait_control))
> + return;
> +
Does the host value ever change? If not, this can perhaps be read once
when kvm_intel is loaded. And if it changes often, it should be
shadowed into a percpu v
On 24/05/19 09:56, Tao Xu wrote:
> As the latest Intel 64 and IA-32 Architectures Software Developer's
> Manual, UMWAIT and TPAUSE instructions cause a VM exit if the
> “RDTSC exiting” and “enable user wait and pause” VM-execution controls
> are both 1.
>
> This patch is to handle the vm-exit for
On 28/05/19 09:19, Tao Xu wrote:
>
> Thank you! This information really helped me. After I read the code in
> KVM/QEMU, I was wondering that with qemu command-line "-cpu
> host,+kvm-hint-dedicated", then in KVM,
> "kvm_hint_has_feature(KVM_HINTS_DEDICATED)" will be true, am I right?
Yes, but it d
On 27/05/19 12:30, Peter Zijlstra wrote:
>> This patch adds support for UMONITOR, UMWAIT and TPAUSE instructions
>> in kvm, and by default dont't expose it to kvm and provide a capability
>> to enable it.
>
> I'm thinking this should be conditional on the guest being a 1:1 guest,
> and I also seem
On 24/05/19 09:56, Tao Xu wrote:
> +7.19 KVM_CAP_ENABLE_USR_WAIT_PAUSE
> +
> +Architectures: x86
> +Parameters: args[0] whether feature should be enabled or not
> +
> +With this capability enabled, a VM can use UMONITOR, UMWAIT and TPAUSE
> +instructions. If the instruction causes a delay, the amou
On 04/11/2018 18:11, Ahmed Abd El Mawgood wrote:
> Our model assumes that an attacker got full root access to a running guest and
> his goal is to manipulate kernel code/data (hook syscalls, overwrite IDT
> ..etc).
>
> There is future work in progress to also put some sort of protection on the
>
On 18/05/2018 19:13, Eduardo Habkost wrote:
>> As much as we'd like to be helpful and validate input, you need a real
>> time host too. I'm not sure how we'd find out - I suggest we do not
>> bother for now.
> I'm worried that people will start enabling the flag in all kinds
> of scenarios where th
On 18/05/2018 18:04, Eduardo Habkost wrote:
>> Without mlock you should always use pv spinlocks.
>>
>> Otherwise you risk blocking on a lock taken by
>> a VCPU that is in turn blocked on IO, where the IO
>> is not completing because CPU is being used up
>> spinning.
>
> So the stronger guarantee se
On 17/05/2018 20:46, Eduardo Habkost wrote:
> My understanding of the original patch is that the intention is
> to tell the guest that it is very unlikely to be preempted, so it
> can choose a more appropriate spinlock implementation. This
> description implies that the guest will never be preempt
On 17/05/2018 16:54, Michael S. Tsirkin wrote:
> HINTS_DEDICATED seems to be somewhat confusing:
>
> Guest doesn't really care whether it's the only task running on a host
> CPU as long as it's not preempted.
>
> And there are more reasons for Guest to be preempted than host CPU
> sharing, for ex
On 10/11/2017 07:07, Wanpeng Li wrote:
>>> You should also add a cpuid flag in kvm part.
>> It is better without that. The flag has no dependency on KVM (kernel
>> hypervisor) code.
> Do you mean -cpu host, +，I think it will result in "warning: host
> doesn't support requested feature: CPUID.4
On 07/11/2017 13:39, Eduardo Valentin wrote:
>> is this still needed after Waiman's patch to adaptively switch between
>> tas and pvqspinlock?
> Can you please point me to it ? Is it already in tip/master?
>
No, he just posted it:
https://marc.info/?l=linux-kernel&m=150972337909996&w=2
Paolo
--
NHALT = 0: default is tas
Hi Eduardo,
besides the suggestion to use a separate word than the one for features,
is this still needed after Waiman's patch to adaptively switch between
tas and pvqspinlock?
Paolo
> Cc: Paolo Bonzini
> Cc: "Radim Krčmář"
> Cc: Jonathan Corbet
On 02/11/2017 19:43, Eduardo Valentin wrote:
> On Thu, Nov 02, 2017 at 07:24:16PM +0100, Paolo Bonzini wrote:
>> On 02/11/2017 19:08, Eduardo Valentin wrote:
>>> On Thu, Nov 02, 2017 at 06:56:46PM +0100, Paolo Bonzini wrote:
>>>> On 02/11/2017 18:45, Eduardo Valent
On 02/11/2017 19:08, Eduardo Valentin wrote:
> On Thu, Nov 02, 2017 at 06:56:46PM +0100, Paolo Bonzini wrote:
>> On 02/11/2017 18:45, Eduardo Valentin wrote:
>>> Currently, the existing qspinlock implementation will fallback to
>>> test-and-set if the hypervisor has
w would you use it?)
Thanks,
Paolo
> Cc: Paolo Bonzini
> Cc: "Radim Krčmář"
> Cc: Jonathan Corbet
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.org
> Cc: Peter Zijlstra
> Cc: Waiman Long
> Cc: k...@vg
On 13/08/2017 21:51, Peng Hao wrote:
> some versions of windows guest access rtc frequently because of
> rtc as system tick.guest access rtc like this: write register index
> to 0x70, then write or read data from 0x71. writing 0x70 port is
> just as index and do nothing else. So we can use coalesce
On 27/06/2017 16:22, Radim Krčmář wrote:
> vcpu_is_preempted() on current cpu cannot return true, AFAIK.
Of course. I must have been thinking of an older version of the
vcpu_is_preempted patch (at some point the guest was the one that set
preempted to 0).
Paolo
--
To unsubscribe from this list
On 27/06/2017 15:40, Radim Krčmář wrote:
>> ... which is not necessarily _wrong_. It's just a different heuristic.
> Right, it's just harder to use than host's single_task_running() -- the
> VCPU calling vcpu_is_preempted() is never preempted, so we have to look
> at other VCPUs that are not hal
On 27/06/2017 14:23, Wanpeng Li wrote:
I have considered single_task_running() before. But since there is no
such paravirtual interface currently and i am not sure whether it is a
information leak from host if introducing such interface, so i didn't do
it. Do you mean vcpu_is_
On 27/06/2017 13:22, Yang Zhang wrote:
>>>
>>> Regarding the good/bad idea part, KVM's polling is made much more
>>> acceptable by single_task_running(). At least you need to integrate it
>>> with paravirtualization. If the VM is scheduled out, you shrink the
>>> polling period. There is alrea
On 22/06/2017 13:22, root wrote:
> ==
>
> +poll_grow: (X86 only)
> +
> +This parameter is multiplied in the grow_poll_ns() to increase the poll time.
> +By default, the values is 2.
> +
> +=
On 27/04/2017 23:57, Jonathan Corbet wrote:
> On Thu, 27 Apr 2017 15:40:42 -0600
> Jonathan Corbet wrote:
>
>> On Mon, 24 Apr 2017 11:16:49 +0200
>> Jann Horn wrote:
>>
>>> Since commit 80f5b5e700fa9c ("KVM: remove vm mmap method"), the VM mmap
>>> handler is gone. Remove the corresponding doc
On 21/04/2017 12:05, Alexander Graf wrote:
>
>
> On 21.04.17 12:02, Paolo Bonzini wrote:
>>
>>
>> On 12/04/2017 18:29, Michael S. Tsirkin wrote:
>>> I don't really agree we do not need the PV flag. mwait on kvm is
>>> different from mwait
On 12/04/2017 18:29, Michael S. Tsirkin wrote:
> I don't really agree we do not need the PV flag. mwait on kvm is
> different from mwait on bare metal in that you are heavily penalized by
> scheduler for polling unless you configure the host just so.
> HLT lets you give up the host CPU if you kno
On 03/03/2017 13:37, James Hogan wrote:
> Actually I think the way I had designed KVM_CAP_MIPS_VZ is fine. I had
> defined it as an enumeration rather than a mask because it isn't
> expected you'd have more than one hardware virtualisation type able to
> run on a particular core.
>
> Whether T&E
On 17/02/2017 17:51, Tom Lendacky wrote:
>
> It's meant just to notify the user about the condition. The user could
> then decide to use an alternative device that supports a greater DMA
> range (I can probably change it to a dev_warn_once() so that a device
> is identified). I would be nice if
On 02/03/2017 12:39, James Hogan wrote:
> It can't right now, though with relocation of the kernel now implemented
> in MIPS Linux for KASLR, and hopes for a more generic EVA implementation
> (which can require the kernel to be linked in a completely different
> segment) it isn't completely infea
On 02/03/2017 10:36, James Hogan wrote:
> - KVM_VM_MIPS_DEFAULT = 2
>
>This will provide the best available KVM implementation (even on
>older kernels), preferring hardware assisted virtualization over trap
>& emulate. The KVM_CAP_MIPS_VZ capability should always be checked
>aga
On 06/02/2017 11:46, James Hogan wrote:
> Documentation/virtual/kvm/api.txt seems to suggest that
> KVM_EXIT_HYPERCALL is obsolete. When it suggests using KVM_EXIT_MMIO,
> does it simply mean the guest should use MMIO to some virtio device of
> some sort rather than using hypercalls, or that the
On 23/01/2017 14:42, Markus Heiser wrote:
>
> Am 04.01.2017 um 23:06 schrieb Jonathan Corbet :
>
>> On Mon, 2 Jan 2017 16:22:22 +0100
>> Paolo Bonzini wrote:
>>
>>> these patches are the result of my experiments with using kernel-doc
>>> for QEM
On 03/01/2017 10:57, Jani Nikula wrote:
> On Mon, 02 Jan 2017, Paolo Bonzini wrote:
>> Hi,
>>
>> these patches are the result of my experiments with using kernel-doc
>> for QEMU's documentation. Patches 1 and 2 should be relatively
>> straightforward, as t
only prints the struct name, to avoid any undesired change in
the operation of docproc.
Signed-off-by: Paolo Bonzini
---
scripts/kernel-doc | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index e5b5d
on, before the return type. To correctly handle this case,
you need to strip spaces after the attributes; otherwise, dump_function
is left confused.
Signed-off-by: Paolo Bonzini
---
scripts/kernel-doc | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/scripts/kernel-doc
he name (before, $1 was pretty much a constant).
Signed-off-by: Paolo Bonzini
---
scripts/kernel-doc | 68 +++---
1 file changed, 50 insertions(+), 18 deletions(-)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 88c3290b6056..daf5e36055
**
``int (*)(int x,int y) bar``
a parameter
Collapse the spaces so that the output is nicer.
Signed-off-by: Paolo Bonzini
---
scripts/kernel-doc | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 030fc633acd4..c1ea91c2e497
The restructuredText output includes both the parameter type and
the name for functions and function-typed members. Do the same
for docbook.
Signed-off-by: Paolo Bonzini
---
scripts/kernel-doc | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/scripts/kernel-doc b
t and output of the rST backend.
I am not sure what is the state of the kernel-doc non-rST backends;
but there are still several books using the docbook workflow, so I'm
trying my luck and sending the patches anyway. :)
Paolo
Paolo Bonzini (5):
kernel-doc: cleanup parameter type in func
On 09/05/2016 23:08, Tom Lendacky wrote:
> On 05/09/2016 10:13 AM, Paolo Bonzini wrote:
>>
>>
>> On 02/05/2016 20:31, Andy Lutomirski wrote:
>>> And did the SEV implementation remember to encrypt the guest register
>>> state? Because, if not, everything
On 02/05/2016 20:31, Andy Lutomirski wrote:
> And did the SEV implementation remember to encrypt the guest register
> state? Because, if not, everything of importance will leak out
> through the VMCB and/or GPRs.
No, it doesn't. And SEV is very limited unless you paravirtualize
everything.
Fo
55 matches
Mail list logo
