Re: [PATCH v2 0/2] KVM: x86: expose direct stores instructions into VM.

On Mon, Nov 5, 2018 at 10:01 PM Liu Jingqi wrote: > > Direct stores instructions MOVDIRI and MOVDIR64B will be available in > Tremont and other future x86 processors, > and need to be exposed to guest VM. It seems like KVM's emulator should be able to complete these instructions to emulated MMIO

Re: [PATCH v2 0/2] KVM: x86: expose direct stores instructions into VM.

On Mon, Nov 5, 2018 at 10:01 PM Liu Jingqi wrote: > > Direct stores instructions MOVDIRI and MOVDIR64B will be available in > Tremont and other future x86 processors, > and need to be exposed to guest VM. It seems like KVM's emulator should be able to complete these instructions to emulated MMIO

Re: [PATCH 4/4] kvm, vmx: remove manually coded vmx instructions

On Wed, Oct 24, 2018 at 1:30 AM Julian Stecklina wrote: > > So far the VMX code relied on manually assembled VMX instructions. This > was apparently done to ensure compatibility with old binutils. VMX > instructions were introduced with binutils 2.19 and the kernel currently > requires binutils

Re: [PATCH 4/4] kvm, vmx: remove manually coded vmx instructions

On Wed, Oct 24, 2018 at 1:30 AM Julian Stecklina wrote: > > So far the VMX code relied on manually assembled VMX instructions. This > was apparently done to ensure compatibility with old binutils. VMX > instructions were introduced with binutils 2.19 and the kernel currently > requires binutils

Re: [PATCH 00/12] KVM: x86: add support for VMX TSC scaling

erent host TSC rates. > > VMX TSC scaling shares some common logics with SVM TSC scaling which > is already supported by KVM. Patch 1 ~ 8 move those common logics from > SVM code to the common code. Upon them, patch 9 ~ 12 add VMX-specific > support for VMX TSC scaling. reviewed-by

Re: [PATCH 01/12] KVM: x86: Collect information for setting TSC scaling ratio

On Sun, Sep 27, 2015 at 10:38 PM, Haozhong Zhang wrote: > > The number of bits of the fractional part of the 64-bit TSC scaling > ratio in VMX and SVM is different. This patch makes the architecture > code to collect the number of fractional bits and other related > information into variables

Re: [PATCH 01/12] KVM: x86: Collect information for setting TSC scaling ratio

On Sun, Sep 27, 2015 at 10:38 PM, Haozhong Zhang wrote: > > The number of bits of the fractional part of the 64-bit TSC scaling > ratio in VMX and SVM is different. This patch makes the architecture > code to collect the number of fractional bits and other related >

Re: [PATCH 00/12] KVM: x86: add support for VMX TSC scaling

migrated among machines with different host TSC rates. > > VMX TSC scaling shares some common logics with SVM TSC scaling which > is already supported by KVM. Patch 1 ~ 8 move those common logics from > SVM code to the common code. Upon them, patch 9 ~ 12 add VMX-specific > support

Re: [PATCH] vhost: support upto 509 memory regions

On Tue, Feb 17, 2015 at 4:32 AM, Michael S. Tsirkin wrote: > On Tue, Feb 17, 2015 at 11:59:48AM +0100, Paolo Bonzini wrote: >> >> >> On 17/02/2015 10:02, Michael S. Tsirkin wrote: >> > > Increasing VHOST_MEMORY_MAX_NREGIONS from 65 to 509 >> > > to match KVM_USER_MEM_SLOTS fixes issue for

Re: [PATCH] vhost: support upto 509 memory regions

On Tue, Feb 17, 2015 at 4:32 AM, Michael S. Tsirkin m...@redhat.com wrote: On Tue, Feb 17, 2015 at 11:59:48AM +0100, Paolo Bonzini wrote: On 17/02/2015 10:02, Michael S. Tsirkin wrote: Increasing VHOST_MEMORY_MAX_NREGIONS from 65 to 509 to match KVM_USER_MEM_SLOTS fixes issue for

Re: [PATCH RFC] virtio_pci: fix virtio spec compliance on restore

On Tue, Sep 23, 2014 at 3:32 AM, Michael S. Tsirkin wrote: > On restore, virtio pci does the following: > + set features > + init vqs etc - device can be used at this point! > + set ACKNOWLEDGE,DRIVER and DRIVER_OK status bits > > This is in violation of the virtio spec, which > requires the

Re: [PATCH RFC] virtio_pci: fix virtio spec compliance on restore

On Tue, Sep 23, 2014 at 3:32 AM, Michael S. Tsirkin m...@redhat.com wrote: On restore, virtio pci does the following: + set features + init vqs etc - device can be used at this point! + set ACKNOWLEDGE,DRIVER and DRIVER_OK status bits This is in violation of the virtio spec, which requires

Re: [PATCH] KVM: x86 emulator: emulate MOVNTDQ

On Fri, Jul 11, 2014 at 10:56 AM, Alex Williamson wrote: > Windows 8.1 guest with NVIDIA driver and GPU fails to boot with an > emulation failure. The KVM spew suggests the fault is with lack of > movntdq emulation (courtesy of Paolo): > > Code=02 00 00 b8 08 00 00 00 f3 0f 6f 44 0a f0 f3 0f 6f

Re: [PATCH] KVM: x86 emulator: emulate MOVNTDQ

On Fri, Jul 11, 2014 at 10:56 AM, Alex Williamson alex.william...@redhat.com wrote: Windows 8.1 guest with NVIDIA driver and GPU fails to boot with an emulation failure. The KVM spew suggests the fault is with lack of movntdq emulation (courtesy of Paolo): Code=02 00 00 b8 08 00 00 00 f3 0f

Re: [PATCH 3/3] KVM: x86: correct mwait and monitor emulation

it wrote: > On 6/18/14, 8:59 PM, Eric Northup wrote: >> >> On Wed, Jun 18, 2014 at 7:19 AM, Nadav Amit >> wrote: >>> >>> mwait and monitor are currently handled as nop. Considering this >>> behavior, they >>> should still be handled correctly

Re: [PATCH 3/3] KVM: x86: correct mwait and monitor emulation

On Wed, Jun 18, 2014 at 7:19 AM, Nadav Amit wrote: > mwait and monitor are currently handled as nop. Considering this behavior, > they > should still be handled correctly, i.e., check execution conditions and > generate > exceptions when required. mwait and monitor may also be executed in

Re: [PATCH 3/3] KVM: x86: correct mwait and monitor emulation

On Wed, Jun 18, 2014 at 7:19 AM, Nadav Amit na...@cs.technion.ac.il wrote: mwait and monitor are currently handled as nop. Considering this behavior, they should still be handled correctly, i.e., check execution conditions and generate exceptions when required. mwait and monitor may also be

Re: [PATCH 3/3] KVM: x86: correct mwait and monitor emulation

...@gmail.com wrote: On 6/18/14, 8:59 PM, Eric Northup wrote: On Wed, Jun 18, 2014 at 7:19 AM, Nadav Amit na...@cs.technion.ac.il wrote: mwait and monitor are currently handled as nop. Considering this behavior, they should still be handled correctly, i.e., check execution conditions and generate

Re: [PATCH 4/4] kvm: Implement PEBS virtualization

On Thu, May 29, 2014 at 6:12 PM, Andi Kleen wrote: > From: Andi Kleen > > PEBS (Precise Event Bases Sampling) profiling is very powerful, > allowing improved sampling precision and much additional information, > like address or TSX abort profiling. cycles:p and :pp uses PEBS. > > This patch

Re: [PATCH 4/4] kvm: Implement PEBS virtualization

On Thu, May 29, 2014 at 6:12 PM, Andi Kleen a...@firstfloor.org wrote: From: Andi Kleen a...@linux.intel.com PEBS (Precise Event Bases Sampling) profiling is very powerful, allowing improved sampling precision and much additional information, like address or TSX abort profiling. cycles:p and

Re: [PATCH V12 3/5] kvm : Fold pv_unhalt flag into GET_MP_STATE ioctl to aid migration

On Tue, Aug 6, 2013 at 11:23 AM, Raghavendra K T wrote: > kvm : Fold pv_unhalt flag into GET_MP_STATE ioctl to aid migration > > From: Raghavendra K T > > During migration, any vcpu that got kicked but did not become runnable > (still in halted state) should be runnable after migration. If this

Re: [PATCH V12 3/5] kvm : Fold pv_unhalt flag into GET_MP_STATE ioctl to aid migration

On Tue, Aug 6, 2013 at 11:23 AM, Raghavendra K T raghavendra...@linux.vnet.ibm.com wrote: kvm : Fold pv_unhalt flag into GET_MP_STATE ioctl to aid migration From: Raghavendra K T raghavendra...@linux.vnet.ibm.com During migration, any vcpu that got kicked but did not become runnable (still

Re: [PATCH 6/6] x86: kaslr: relocate base offset at boot

W/the relocation information, we can pick the virtual address to load at independent from the physical load address. On Mon, Apr 15, 2013 at 2:41 PM, Kees Cook wrote: > On Mon, Apr 15, 2013 at 2:25 PM, H. Peter Anvin wrote: >> On 04/15/2013 02:06 PM, Eric Northup wrote: >>> On

Re: [PATCH 6/6] x86: kaslr: relocate base offset at boot

On Sat, Apr 13, 2013 at 8:06 PM, H. Peter Anvin wrote: > On 04/13/2013 05:37 PM, Yinghai Lu wrote: >> >> so decompress code position is changed? >> >> You may push out bss and other data area of run-time kernel of limit >> that boot loader >> chose according to setup_header.init_size. >> aka that

Re: [PATCH 6/6] x86: kaslr: relocate base offset at boot

On Sat, Apr 13, 2013 at 8:06 PM, H. Peter Anvin h...@zytor.com wrote: On 04/13/2013 05:37 PM, Yinghai Lu wrote: so decompress code position is changed? You may push out bss and other data area of run-time kernel of limit that boot loader chose according to setup_header.init_size. aka that

Re: [PATCH 6/6] x86: kaslr: relocate base offset at boot

W/the relocation information, we can pick the virtual address to load at independent from the physical load address. On Mon, Apr 15, 2013 at 2:41 PM, Kees Cook keesc...@chromium.org wrote: On Mon, Apr 15, 2013 at 2:25 PM, H. Peter Anvin h...@zytor.com wrote: On 04/15/2013 02:06 PM, Eric Northup

Re: [PATCH] x86: make IDT read-only

IDT unconditionally read-only. This primarily removes >>> >> the IDT from being a target for arbitrary memory write attacks. It has >>> >> an added benefit of also not leaking (via the "sidt" instruction) the >>> >> kernel base offset, if it

Re: [PATCH] x86: make IDT read-only

-only. This primarily removes the IDT from being a target for arbitrary memory write attacks. It has an added benefit of also not leaking (via the sidt instruction) the kernel base offset, if it has been relocated. Signed-off-by: Kees Cook keesc...@chromium.org Cc: Eric Northup digitale

Re: [kernel-hardening] Re: [PATCH] x86: make IDT read-only

On Tue, Apr 9, 2013 at 11:46 AM, Kees Cook wrote: > On Tue, Apr 9, 2013 at 11:39 AM, H. Peter Anvin wrote: >> On 04/09/2013 11:31 AM, Kees Cook wrote: > ... > 0x880001e0-0x88001fe0 480M RW PSE GLB > NX pmd > That is the 1:1 memory

Re: [kernel-hardening] Re: [PATCH] x86: make IDT read-only

On Tue, Apr 9, 2013 at 11:46 AM, Kees Cook keesc...@chromium.org wrote: On Tue, Apr 9, 2013 at 11:39 AM, H. Peter Anvin h...@zytor.com wrote: On 04/09/2013 11:31 AM, Kees Cook wrote: ... 0x880001e0-0x88001fe0 480M RW PSE GLB NX pmd That is the 1:1

Re: [PATCH 3/3] x86: kernel base offset ASLR

On Thu, Apr 4, 2013 at 2:01 PM, H. Peter Anvin wrote: > What system monitoring? Most systems don't have much... The security of an unmonitored system is going to be much lower than of a well-monitored system. That's true independent of whether kASLR is deployed. > > Kees Cook wrote: > >>On

Re: [PATCH 3/3] x86: kernel base offset ASLR

On Thu, Apr 4, 2013 at 1:58 PM, H. Peter Anvin wrote: > It seems to me that you are assuming that the attacker is targeting a > specific system, but a bot might as well target 256 different systems and see > what sticks... The alarm signal from the ones that don't stick is, in my opinion, the

Re: [PATCH 3/3] x86: kernel base offset ASLR

On Thu, Apr 4, 2013 at 1:21 PM, H. Peter Anvin wrote: > I have to admit to being somewhat skeptical toward KASLR with only 8 > bits of randomness. I agree that 8 bits is pretty low and more would be better. However, even 8 bits provides a < 1% chance that any particular guess will be correct.

Re: [PATCH 3/3] x86: kernel base offset ASLR

On Thu, Apr 4, 2013 at 1:21 PM, H. Peter Anvin h...@zytor.com wrote: I have to admit to being somewhat skeptical toward KASLR with only 8 bits of randomness. I agree that 8 bits is pretty low and more would be better. However, even 8 bits provides a 1% chance that any particular guess will be

Re: [PATCH 3/3] x86: kernel base offset ASLR

On Thu, Apr 4, 2013 at 1:58 PM, H. Peter Anvin h...@zytor.com wrote: It seems to me that you are assuming that the attacker is targeting a specific system, but a bot might as well target 256 different systems and see what sticks... The alarm signal from the ones that don't stick is, in my

Re: [PATCH 3/3] x86: kernel base offset ASLR

On Thu, Apr 4, 2013 at 2:01 PM, H. Peter Anvin h...@zytor.com wrote: What system monitoring? Most systems don't have much... The security of an unmonitored system is going to be much lower than of a well-monitored system. That's true independent of whether kASLR is deployed. Kees Cook

Re: [PATCH 5/5] KVM: MMU: fast invalid all mmio sptes

On Fri, Mar 15, 2013 at 8:29 AM, Xiao Guangrong wrote: > This patch tries to introduce a very simple and scale way to invalid all > mmio sptes - it need not walk any shadow pages and hold mmu-lock > > KVM maintains a global mmio invalid generation-number which is stored in >

Re: [PATCH 5/5] KVM: MMU: fast invalid all mmio sptes

On Fri, Mar 15, 2013 at 8:29 AM, Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote: This patch tries to introduce a very simple and scale way to invalid all mmio sptes - it need not walk any shadow pages and hold mmu-lock KVM maintains a global mmio invalid generation-number which is

[PATCH] virtio_scsi: fix memory leak on full queue condition.

virtscsi_queuecommand was leaking memory when the virtio queue was full. Tested: Guest operates correctly even with very small queue sizes, validated we're not leaking kmalloc-192 sized allocations anymore. Signed-off-by: Eric Northup --- drivers/scsi/virtio_scsi.c |2 ++ 1 files changed

[PATCH] virtio_scsi: fix memory leak on full queue condition.

virtscsi_queuecommand was leaking memory when the virtio queue was full. Tested: Guest operates correctly even with very small queue sizes, validated we're not leaking kmalloc-192 sized allocations anymore. Signed-off-by: Eric Northup digitale...@google.com --- drivers/scsi/virtio_scsi.c |2