Il 18/09/2014 23:54, David Hepkin ha scritto:
The chief advantage I see to using a hypercall based mechanism is
that it would work across more architectures. MSR's and CPUID's are
specific to X86. If we ever wanted this same mechanism to be
available on an architecture that doesn't support
Il 19/09/2014 05:58, Andres Lagar-Cavilla ha scritto:
Paolo, should I recut including the recent Reviewed-by's?
No, I'll add them myself.
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at
https://bugzilla.kernel.org/show_bug.cgi?id=84781
Paolo Bonzini bonz...@gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
On 09/19/2014 12:38 AM, Liang Chen wrote:
A one-line wrapper around kvm_make_request does not seem
particularly useful. Replace kvm_mmu_flush_tlb() with
kvm_make_request() again to free the namespace a bit.
Signed-off-by: Liang Chen liangchen.li...@gmail.com
---
On 07/01/2014 06:49 PM, Michael S. Tsirkin wrote:
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/vhost/vhost.h | 19 +--
drivers/vhost/net.c | 30 +-
drivers/vhost/scsi.c | 23 +++
drivers/vhost/test.c | 5
On Thu, Sep 18, 2014 at 03:36:43PM +0200, Paolo Bonzini wrote:
We're talking about the case where the field is not reserved anymore and
we _know_ that the vendor has just decided to grow the bitfield that
precedes it.
We're talking about the case where you assumed that a reserved bit is 0
On Sep 19, 2014, at 10:58 AM, Borislav Petkov b...@alien8.de wrote:
On Thu, Sep 18, 2014 at 03:36:43PM +0200, Paolo Bonzini wrote:
We're talking about the case where the field is not reserved anymore and
we _know_ that the vendor has just decided to grow the bitfield that
precedes it.
On 07/01/2014 06:49 PM, Michael S. Tsirkin wrote:
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/vhost/vhost.h | 19 +--
drivers/vhost/net.c | 30 +-
drivers/vhost/scsi.c | 23 +++
drivers/vhost/test.c | 5
From: Frank Blaschka frank.blasc...@de.ibm.com
Following changes are made because of platform differences:
1) s390 does not support mmap'ing of PCI BARs so we have to go via slow path
2) no intx support
3) no classic MSIX interrupts. The pci hw understands the concept
of requesting MSIX irqs
From: Frank Blaschka frank.blasc...@de.ibm.com
This patch adds some small changes to make vfio build on s390.
Signed-off-by: Frank Blaschka frank.blasc...@de.ibm.com
---
drivers/vfio/Kconfig |2 +-
drivers/vfio/pci/vfio_pci_rdwr.c |8
2 files changed, 9
This set of patches implements a vfio based solution for pci
pass-through on the s390 platform. The kernel stuff is pretty
much straight forward, but qemu needs more work.
Most interesting patch is:
vfio: make vfio run on s390 platform
I hope Alex Alex can give me some guidance how to do the
From: Frank Blaschka frank.blasc...@de.ibm.com
This patch implements a pci bus for s390x together with some infrastructure
to generate and handle hotplug events. It also provides device
configuration/unconfiguration via sclp instruction interception.
Signed-off-by: Frank Blaschka
From: Frank Blaschka frank.blasc...@de.ibm.com
Add a basic iommu for the s390 platform. The code is pretty
simple since on s390 each PCI device has its own virtual io address
space starting at the same vio address. For this a domain could
hold only one pci device. Also there is no relation
Enable PCI instructions for s390 KVM.
Signed-off-by: Frank Blaschka frank.blasc...@de.ibm.com
---
arch/s390/kvm/kvm-s390.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -1787,7 +1787,7 @@ static int __init
On Fri, Sep 19, 2014 at 11:59:32AM +0300, Nadav Amit wrote:
As for the concern that CPUID fields would be extended into non-zero
reserved bits - can someone point me to a single case that occurred in
the last 20 years during which CPUID existed?
Do you have a guarantee that this won't happen
2014-09-19 14:12+0800, Xiao Guangrong:
On 09/19/2014 12:38 AM, Liang Chen wrote:
A one-line wrapper around kvm_make_request does not seem
particularly useful. Replace kvm_mmu_flush_tlb() with
kvm_make_request() again to free the namespace a bit.
Signed-off-by: Liang Chen
On 09/18/2014 11:04 AM, David Hildenbrand wrote:
This patch should fix the bug reported in https://lkml.org/lkml/2014/9/11/249.
We have to initialize at least the atomic_flags and the cmd_flags when
allocating storage for the requests.
Otherwise blk_mq_timeout_check() might dereference
Il 18/09/2014 23:24, Marcelo Tosatti ha scritto:
Initilization of L2 guest with -cpu host, on L1 guest with -cpu host
triggers:
(qemu) KVM: entry failed, hardware error 0x7
...
nested_vmx_run: VMCS MSR_{LOAD,STORE} unsupported
Nested VMX MSR load/store support is not sufficient to
Il 19/09/2014 01:40, Sam Bobroff ha scritto:
Correct a simple mistake of checking the wrong variable
before a dereference, resulting in the dereference not being
properly protected by rcu_dereference().
Signed-off-by: Sam Bobroff sam.bobr...@au1.ibm.com
---
virt/kvm/kvm_main.c | 2 +-
Il 19/09/2014 07:53, Fam Zheng ha scritto:
Any ideas?
The obvious, but hardish one is to switch to epoll (one epoll fd per
AioContext, plus one for iohandler.c).
This would require converting iohandler.c to a GSource.
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the
On 09/19/2014 08:25 PM, Radim Krčmář wrote:
* Returns 1 to let __vcpu_run() continue the guest execution loop without
* exiting to the userspace. Otherwise, the value will be returned to the
@@ -6018,8 +6024,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
if
Il 19/09/2014 09:58, Borislav Petkov ha scritto:
The trivial example is feature bits like XSAVE. We query them all the
time without checking the family when they were first introduced,
don't we?
The feature bits would obviously be 0 if features are not supported.
And similarly, Intel would
Il 19/09/2014 15:35, Xiao Guangrong ha scritto:
Which is why just removing it solves more problems for me :)
Thank you for raising this question and letting me know the patch's history.
:)
I agree with Radim, so I'll apply the patch.
Paolo
--
To unsubscribe from this list: send the line
On 09/19/2014 02:12 AM, Xiao Guangrong wrote:
On 09/19/2014 12:38 AM, Liang Chen wrote:
A one-line wrapper around kvm_make_request does not seem
particularly useful. Replace kvm_mmu_flush_tlb() with
kvm_make_request() again to free the namespace a bit.
Signed-off-by: Liang Chen
On 18 September 2014 05:18, Laszlo Ersek ler...@redhat.com wrote:
On 09/18/14 13:44, Andreas Färber wrote:
Hello Laszlo,
Am 18.09.2014 um 10:23 schrieb Laszlo Ersek:
I've been made an offer that I couldn't refuse :) to organize a Birds
of a Feather session concerning OVMF at the KVM Forum
From: Jason J. Herne jjhe...@us.ibm.com
Enable KVM_SET_CLOCK and KVM_GET_CLOCK Ioctls on S390 for managing guest TOD
clock value.
we add the KVM_CLOCK_FORWARD_ONLY flag to indicate to KVM_SET_CLOCK that the
given clock value should only be set if it is = the current guest TOD clock
value. This
oops, didn't see this ;) Thank you!
Thanks,
Liang
On 09/19/2014 10:00 AM, Paolo Bonzini wrote:
Il 19/09/2014 15:35, Xiao Guangrong ha scritto:
Which is why just removing it solves more problems for me :)
Thank you for raising this question and letting me know the patch's history.
:)
I
On Fri, Sep 19, 2014 at 03:40:29PM +0200, Paolo Bonzini wrote:
And similarly, Intel would not extend a bit from 16 to 17 bits if it
weren't zero on all older processors.
Nothing is stopping a hw designer to say we're using 17 bits now. And
software needs to deal with that. It is that simple!
Hi Frank,
On Fri, 19 Sep 2014 13:54:34 +0200
frank.blasc...@de.ibm.com wrote:
From: Frank Blaschka frank.blasc...@de.ibm.com
This patch implements the s390 pci instructions in qemu. This allows
to attach qemu pci devices including vfio. This does not mean the
devices are functional but
On Tue, Sep 09, 2014 at 12:08:52AM +0100, Joel Schopp wrote:
The current VTTBR_BADDR_MASK only masks 39 bits, which is broken on current
systems. Rather than just add a bit it seems like a good time to also set
things at run-time instead of compile time to accomodate more hardware.
This
On Thu, Sep 18, 2014 at 6:28 PM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Sep 18, 2014 at 6:03 PM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun jun.nakaj...@intel.com
wrote:
On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski
Il 19/09/2014 18:14, Nakajima, Jun ha scritto:
For example,
- CPUID 0x4801.EAX would return the feature presence (e.g. in
EBX), and the result in EDX:EAX (if present) at the same time, or
- CPUID 0x4801.EAX would return the feature presence only, and
CPUID 0x4802.EAX (acts like a
On 09/19/2014 09:37 AM, Gleb Natapov wrote:
Linux detects what hypervior it runs on very early
Not anywhere close to early enough. We're talking for uses like kASLR.
-hpa
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
On 09/19/2014 09:14 AM, Nakajima, Jun wrote:
I slept on it, and I think using the CPUID instruction alone would be
simple and efficient:
- We have a huge space for CPUID leaves
- CPUID also works for user-level
- It can take an additional 32-bit parameter (ECX), and returns 4
32-bit values
On Thu, Sep 18, 2014 at 03:00:05PM -0700, Andy Lutomirski wrote:
On Thu, Sep 18, 2014 at 2:46 PM, David Hepkin david...@microsoft.com wrote:
I suggest we come to consensus on a specific CPUID leaf where an OS needs
to look to determine if a hypervisor supports this capability. We could
On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:37 AM, Gleb Natapov wrote:
Linux detects what hypervior it runs on very early
Not anywhere close to early enough. We're talking for uses like kASLR.
Still to early to do:
h = cpuid(HYPERVIOR_SIGNATURE)
Il 19/09/2014 16:17, Ard Biesheuvel ha scritto:
(**) Ard's patches for the upstream host kernel (== KVM) have been...
ugh, not sure... applied to a maintainer tree? Ard? :)
Some are in kvm/master, which I think means to should go into the next
3.17-rc, although I haven't seen much
On 09/19/2014 09:53 AM, Gleb Natapov wrote:
On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:37 AM, Gleb Natapov wrote:
Linux detects what hypervior it runs on very early
Not anywhere close to early enough. We're talking for uses like kASLR.
Still to early
On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:53 AM, Gleb Natapov wrote:
On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:37 AM, Gleb Natapov wrote:
Linux detects what hypervior it runs on very early
Not anywhere close
On 09/19/2014 10:15 AM, Gleb Natapov wrote:
On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:53 AM, Gleb Natapov wrote:
On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:37 AM, Gleb Natapov wrote:
Linux detects what hypervior it
On 09/19/2014 10:15 AM, Gleb Natapov wrote:
On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:53 AM, Gleb Natapov wrote:
On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:37 AM, Gleb Natapov wrote:
Linux detects what hypervior it
On Sep 19, 2014 9:40 AM, H. Peter Anvin h...@zytor.com wrote:
On 09/19/2014 09:14 AM, Nakajima, Jun wrote:
I slept on it, and I think using the CPUID instruction alone would be
simple and efficient:
- We have a huge space for CPUID leaves
- CPUID also works for user-level
- It can
On Sep 19, 2014 9:53 AM, Gleb Natapov g...@kernel.org wrote:
On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:37 AM, Gleb Natapov wrote:
Linux detects what hypervior it runs on very early
Not anywhere close to early enough. We're talking for uses like
On Fri, Sep 19, 2014 at 04:28:54PM +0100, Catalin Marinas wrote:
On Tue, Sep 09, 2014 at 12:08:52AM +0100, Joel Schopp wrote:
The current VTTBR_BADDR_MASK only masks 39 bits, which is broken on current
systems. Rather than just add a bit it seems like a good time to also set
things at
On 09/19/2014 10:21 AM, Andy Lutomirski wrote:
There is a huge disadvantage to the fact that CPUID is a user space
instruction, though.
We can always make cpuid on the leaf in question return all zeros if CPL 0.
Not sure that is better...
-hpa
--
To unsubscribe from this list:
On Fri, Sep 19, 2014 at 10:36 AM, H. Peter Anvin h...@zytor.com wrote:
On 09/19/2014 10:21 AM, Andy Lutomirski wrote:
There is a huge disadvantage to the fact that CPUID is a user space
instruction, though.
We can always make cpuid on the leaf in question return all zeros if CPL 0.
Not
On Fri, Sep 19, 2014 at 10:18:37AM -0700, H. Peter Anvin wrote:
On 09/19/2014 10:15 AM, Gleb Natapov wrote:
On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:53 AM, Gleb Natapov wrote:
On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
On
On Fri, Sep 19, 2014 at 10:21:27AM -0700, Andy Lutomirski wrote:
On Sep 19, 2014 9:53 AM, Gleb Natapov g...@kernel.org wrote:
On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:37 AM, Gleb Natapov wrote:
Linux detects what hypervior it runs on very
On Fri, Sep 19, 2014 at 10:49 AM, Gleb Natapov g...@kernel.org wrote:
On Fri, Sep 19, 2014 at 10:18:37AM -0700, H. Peter Anvin wrote:
On 09/19/2014 10:15 AM, Gleb Natapov wrote:
On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:53 AM, Gleb Natapov wrote:
On
On 19 September 2014 10:03, Paolo Bonzini pbonz...@redhat.com wrote:
Il 19/09/2014 16:17, Ard Biesheuvel ha scritto:
(**) Ard's patches for the upstream host kernel (== KVM) have been...
ugh, not sure... applied to a maintainer tree? Ard? :)
Some are in kvm/master, which I think means to
On Fri, Sep 19, 2014 at 11:02:38AM -0700, Andy Lutomirski wrote:
On Fri, Sep 19, 2014 at 10:49 AM, Gleb Natapov g...@kernel.org wrote:
On Fri, Sep 19, 2014 at 10:18:37AM -0700, H. Peter Anvin wrote:
On 09/19/2014 10:15 AM, Gleb Natapov wrote:
On Fri, Sep 19, 2014 at 10:08:20AM -0700, H.
[cc: Alok Kataria at VMware]
On Fri, Sep 19, 2014 at 11:12 AM, Gleb Natapov g...@kernel.org wrote:
On Fri, Sep 19, 2014 at 11:02:38AM -0700, Andy Lutomirski wrote:
On Fri, Sep 19, 2014 at 10:49 AM, Gleb Natapov g...@kernel.org wrote:
On Fri, Sep 19, 2014 at 10:18:37AM -0700, H. Peter Anvin
On 09/17/2014 10:50 PM, Andy Lutomirski wrote:
Hi all-
I would like to standardize on a very simple protocol by which a guest
OS can obtain an RNG seed early in boot.
The main design requirements are:
- The interface should be very easy to use. Linux, at least, will
want to use it
On Fri, Sep 19, 2014 at 11:30 AM, Christopher Covington
c...@codeaurora.org wrote:
On 09/17/2014 10:50 PM, Andy Lutomirski wrote:
Hi all-
I would like to standardize on a very simple protocol by which a guest
OS can obtain an RNG seed early in boot.
The main design requirements are:
-
On 09/19/2014 04:19 PM, Jason J. Herne wrote:
From: Jason J. Herne jjhe...@us.ibm.com
Enable KVM_SET_CLOCK and KVM_GET_CLOCK Ioctls on S390 for managing guest TOD
clock value.
Just some education. On s390 the guest visible TOD clock is thehost TOD clock +
hypervisor programmable offset in
On Sep 19, 2014, at 9:42 PM, Andy Lutomirski l...@amacapital.net wrote:
On Fri, Sep 19, 2014 at 11:30 AM, Christopher Covington
c...@codeaurora.org wrote:
On 09/17/2014 10:50 PM, Andy Lutomirski wrote:
Hi all-
I would like to standardize on a very simple protocol by which a guest
OS can
On 19.09.14 20:51, Christian Borntraeger wrote:
On 09/19/2014 04:19 PM, Jason J. Herne wrote:
From: Jason J. Herne jjhe...@us.ibm.com
Enable KVM_SET_CLOCK and KVM_GET_CLOCK Ioctls on S390 for managing guest TOD
clock value.
Just some education. On s390 the guest visible TOD clock is
On Fri, Sep 19, 2014 at 1:21 PM, Nadav Amit nadav.a...@gmail.com wrote:
On Sep 19, 2014, at 9:42 PM, Andy Lutomirski l...@amacapital.net wrote:
On Fri, Sep 19, 2014 at 11:30 AM, Christopher Covington
c...@codeaurora.org wrote:
On 09/17/2014 10:50 PM, Andy Lutomirski wrote:
Hi all-
I would
On Fri, Sep 19, 2014 at 11:20:49AM -0700, Andy Lutomirski wrote:
[cc: Alok Kataria at VMware]
On Fri, Sep 19, 2014 at 11:12 AM, Gleb Natapov g...@kernel.org wrote:
On Fri, Sep 19, 2014 at 11:02:38AM -0700, Andy Lutomirski wrote:
On Fri, Sep 19, 2014 at 10:49 AM, Gleb Natapov
2014-09-19 21:35+0800, Xiao Guangrong:
On 09/19/2014 08:25 PM, Radim Krčmář wrote:
* Returns 1 to let __vcpu_run() continue the guest execution loop
without
* exiting to the userspace. Otherwise, the value will be returned to
the
@@ -6018,8 +6024,7 @@ static int
On 09/19/2014 01:46 PM, Andy Lutomirski wrote:
However, it sounds to me that at least for KVM, it is very easy just to
emulate the RDRAND instruction. The hypervisor would report to the guest
that RDRAND is supported in CPUID and the emulate the instruction when guest
executes it. KVM
On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote:
There is a huge disadvantage to the fact that CPUID is a user space
instruction, though.
But if the goal is to provide something like getrandom(2) direct from
the Host OS, it's not necessarily harmful to allow the Guest ring 3
On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o ty...@mit.edu wrote:
On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote:
There is a huge disadvantage to the fact that CPUID is a user space
instruction, though.
But if the goal is to provide something like getrandom(2) direct from
On Fri, Sep 19, 2014 at 3:06 PM, Andy Lutomirski l...@amacapital.net wrote:
On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o ty...@mit.edu wrote:
On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote:
There is a huge disadvantage to the fact that CPUID is a user space
instruction,
On Fri, Sep 19, 2014 at 03:06:55PM -0700, Andy Lutomirski wrote:
On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o ty...@mit.edu wrote:
On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote:
There is a huge disadvantage to the fact that CPUID is a user space
instruction, though.
vcpu ioctls can hang the calling thread if issued while a vcpu is
running. If we know ioctl is going to be rejected as invalid anyway,
we can fail before trying to take the vcpu mutex.
This patch does not change functionality, it just makes invalid ioctls
fail faster.
Signed-off-by: David
On Fri, Sep 19, 2014 at 3:57 PM, Theodore Ts'o ty...@mit.edu wrote:
On Fri, Sep 19, 2014 at 03:06:55PM -0700, Andy Lutomirski wrote:
On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o ty...@mit.edu wrote:
On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote:
There is a huge
On 09/19/2014 04:12 PM, Andy Lutomirski wrote:
To force deterministic execution.
I incorrectly thought that the kernel could switch RDRAND on and off.
It turns out that a hypervisor can do this, but not the kernel. Also,
determinism is lost anyway because of TSX, which *also* can't be
On 09/19/2014 04:12 PM, Andy Lutomirski wrote:
To force deterministic execution.
I incorrectly thought that the kernel could switch RDRAND on and off.
It turns out that a hypervisor can do this, but not the kernel. Also,
determinism is lost anyway because of TSX, which *also* can't be
On Fri, Sep 19, 2014 at 04:29:53PM -0700, H. Peter Anvin wrote:
Actually, a much bigger reason is because it lets rogue guest *user
space*, even will a well-behaved guest OS, do something potentially
harmful to the host.
Right, but if the host kernel is dependent on the guest OS for
On Fri, Sep 19, 2014 at 4:35 PM, Theodore Ts'o ty...@mit.edu wrote:
On Fri, Sep 19, 2014 at 04:29:53PM -0700, H. Peter Anvin wrote:
Actually, a much bigger reason is because it lets rogue guest *user
space*, even will a well-behaved guest OS, do something potentially
harmful to the host.
2014-09-16 13:38+0200, Paolo Bonzini:
In init_rmode_tss(), there two variables indicating the return
value, r and ret, and it return 0 on error, 1 on success. The function
is only called by vmx_set_tss_addr(), and r is redundant.
This patch removes the redundant variable, by making
On 09/19/2014 04:35 PM, Theodore Ts'o wrote:
On Fri, Sep 19, 2014 at 04:29:53PM -0700, H. Peter Anvin wrote:
Actually, a much bigger reason is because it lets rogue guest *user
space*, even will a well-behaved guest OS, do something potentially
harmful to the host.
Right, but if the host
On 2014/8/21 21:06, Andre Przywara wrote:
With everything in place we allow userland to request the kernel
using a virtual GICv3 in the guest, which finally lifts the 8 vCPU
limit for a guest.
Also we provide the necessary support for guests setting the memory
addresses for the virtual
74 matches
Mail list logo
