.] [|
> 2nd-mnemonic ...]
> EndTable
>
> These opcode maps do NOT include most of SSE and FP opcodes, because
> those opcodes are not used in the kernel.
>
> Signed-off-by: Masami Hiramatsu
> Signed-off-by: Jim Keniston
> Cc: H. Peter Anvin
> Cc: Steven Rostedt
&
Masami Hiramatsu wrote:
These opcode maps do NOT include most of SSE and FP opcodes, because
those opcodes are not used in the kernel.
That is not true.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More m
Yep, NAK on this one.
Borislav Petkov wrote:
>On Fri, Jul 13, 2012 at 08:02:55PM +0200, Davidlohr Bueso wrote:
>> From: Davidlohr Bueso
>>
>> AMD has renamed nested page table technology to rapid virtualization
>indexing,
>> reflect this change in the kernel.
>>
>> Signed-off-by: Davidlohr Bu
ut the overflow in the low byte. But boy is that ugly ;)
>
> But at least you wouldn't need to do the loop with cmpxchg. So it's
> twisted and ugly, but migth be practical.
>
I suspect it should be coded as -254 in order to use a short immediate
if that is even possibl
On 10/14/2011 10:02 AM, Jeremy Fitzhardinge wrote:
>
> Jump labels are essentially binary: you can use path A or path B. pvops
> are multiway: there's no limit to the number of potential number of
> paravirtualized hypervisor implementations. At the moment we have 4:
> native, Xen, KVM and lgues
On 10/14/2011 11:35 AM, Jason Baron wrote:
>
> A nice featuer of jump labels, is that it allows the various branches
> (currently we only support 2), to be written in c code (as opposed to asm),
> which means you can write your code as you normally would and access any
> parameters as you normally
On 10/14/2011 12:10 PM, Jeremy Fitzhardinge wrote:
>
> We probably don't want all those implementations (near) inline, so they
> would end up being plain function calls anyway.
>
I would not object if the native one was closer, though; especially in
term of source text (the current level of macr
nted using the alternatives mechanism.
If nothing else it would be good to:
1. Make more general use of ops patching;
2. Merge mechanisms where practical.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscrib
On 01/07/2012 12:21 PM, Nadav Amit wrote:
> MOV immediate instruction (opcodes 0xB8-0xBF) may take 64-bit operand.
> The previous emulation implementation assumes the operand is no longer than
> 32.
>
> Signed-off-by: Nadav Amit
There are exactly two such instructions: MOV immediate (B8-BF) and
On 01/11/2012 09:19 AM, t...@kernel.org wrote:
Alex, can you please collect all patches into a single patchset?
Please split it such that, usage changes are per-system so that they
can be routed through respective subsystems (x86 or net) and updates
to percpu proper which can be applied after ot
On 04/30/2012 07:39 AM, Michael S. Tsirkin wrote:
> cpuid eax should return the max leaf so that
> guests can find out the valid range.
> This matches Xen et al.
Not to mention it's what all the "real" CPU leaf chunks do.
Acked-by: H. Peter Anvin
--
To unsubscribe from
On 04/30/2012 01:37 PM, Anthony Liguori wrote:
> On 04/30/2012 09:39 AM, Michael S. Tsirkin wrote:
>> cpuid eax should return the max leaf so that
>> guests can find out the valid range.
>> This matches Xen et al.
>
> What KVM does here predates Xen and Hyper-V.
>
> This is an ABI breaker.
>
Wh
I really don't understand
the point of having a private copy here.
I really, really don't want a bunch of private interfaces around. It
would be a lot better to define a test_and_{set,clear}_bit_local() in
which is defined to be local CPU atomic.
-hpa
--
H. Peter Anvin, Intel
unless arch-overridden, but that would be
the best, I would think.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a mess
On 05/09/2012 06:45 AM, Michael S. Tsirkin wrote:
> kvm needs to update some hypervisor variables atomically
> in a sense that the operation can't be interrupted
> in the middle. However the hypervisor always runs
> on the same CPU so it does not need any memory
> barrier or lock prefix.
>
> At Pe
On 05/09/2012 08:43 AM, Michael S. Tsirkin wrote:
>
> Just adding a memory clobber to asm will be enough, right?
>
Yes.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list:
er semantics.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info
s.
For your _local I would just copy the atomic bitops but remote the locks
in most cases.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe kvm"
On 05/09/2012 12:19 PM, Andrew Morton wrote:
>
> Secondly: can KVM just use __set_bit() and friends? I suspect those
> interfaces happen to meet your requirements. At least on architectures
> you care about.
>
__set_bit() and friends right now don't have optimization barriers,
meaning the comp
On 05/09/2012 01:07 PM, Michael S. Tsirkin wrote:
>
> In practice ATM any of the above will work. We probably don't even need
> to add barrier() calls since what we do afterwards is apic access which
> has an optimization barrier anyway. But I'm fine with adding them in
> there just in case if th
On 05/21/2012 04:06 PM, Michael S. Tsirkin wrote:
>
> I think the reason is __apic_read which now simply copies the registers
> out to guest, this code will become less straight-forward if it's not
> 1:1.
>
It can still be 1:1, just drop the 12 bytes of completely useless
padding after each 32-b
gs up
> until the window closes next time.
>
It's generally a good rule for anything for beyond the merge window
(i.e. for 3.6 in this case.)
It is *way* too easy to get down rathole confusions otherwise.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work
ategory of a legitimate need to stick to the hardware format.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majo
On 05/31/2012 01:01 AM, Raghavendra K T wrote:
> +
> +TODO:
> +1. more information on input and output needed?
> +2. Add more detail to purpose of hypercalls.
>
1. definitely, including the hypercall ABI.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I wor
On 05/31/2012 11:55 AM, Jan Kiszka wrote:
>>
>> No "Status", does that imply "Active" ?
>
> It should actually state that this call is in use.
>
It might be nice to point out when a call was introduced, and for
deprecated calls, when it was deprecated.
?
Avi, Marcelo, maybe you can carry this in kvm/linux-next as a temporary
measure so that linux-next builds?
I'm not happy about that as a workflow, but since you guys have an
immediate problem I guess we can do that.
Acked-by: H. Peter Anvin
-hpa
--
H. Peter Anvin, Intel O
On 02/16/2012 09:39 AM, Avi Kivity wrote:
>>
>> Yes, this is on purpose
Why?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe kvm"
n PCIe links. For virtual
devices you have no such limitation. What is the problem again?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the
What is the current status of this patchset? I haven't looked at it too
closely because I have been focused on 3.4 up until now...
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list
On 11/24/2010 09:44 AM, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Add a wbinvd helper for an arbitrary set of CPUs.
>
Are there any expected users of this other than KVM?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don'
Wtf?
This patch seems semibogus at best and the description is even more
ridiculous...
Emil Goode wrote:
>The first patch in this series changes the return type of function
>kvm_para_available to bool. In the function snd_intel8x0_inside_vm
>we now need to check it's return value before assig
ff068c9ef8 error d
>
> and boots to an initramfs prompt.
>
> git bisect (log attached) blames:
>
> commit 7b5c4a65cc27f017c170b025f8d6d75dabb11c6f
> Merge: 3596f5b 949db15
> Author: H. Peter Anvin
> Date: Fri Jan 25 16:31:21 2013 -0800
>
> Merge tag 'v3
es.
Why not simply add a (possibly proprietary) capability to the PCI bridge
to allow a much narrower window? That fits much more nicely into the
device resource assignment on the guest side, and could even be
implemented on a real hardware device -- we can offer it to the PCI-SIG
for standardiz
On 03/05/2013 04:05 PM, H. Peter Anvin wrote:
> On 02/28/2013 07:24 AM, Michael S. Tsirkin wrote:
>>
>> 3. hypervisor assigned IO address
>> qemu can reserve IO addresses and assign to virtio devices.
>> 2 bytes per device (for notification and ISR access) wi
On 03/06/2013 01:21 AM, Michael S. Tsirkin wrote:
>
> Right. Though even with better granularify bridge windows
> would still be a (smaller) problem causing fragmentation.
>
> If we were to extend the PCI spec I would go for a bridge without
> windows at all: a bridge can snoop on configuration t
Is there any preferred way to busy-wait on a virtio event? As in: the
guest doesn't have anything useful to do until something is plopped down
on the virtio queue, but would like to proceed as quickly as possible
after that. Passing through an interrupt handler seems like unnecessary
overhead.
R
On 04/09/2013 05:03 PM, Borislav Petkov wrote:
>
> Note to self: this destroys the src operand but it shouldn't. Fix it
> tomorrow.
>
I thought movbe was already in qemu just not on by default...?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a m
Just to interject here... all this is about host kernel vs userspace, correct?
I.e. nothing that affects the guest. I assume that the guest sees CPUID and
that is what is supported.
Borislav Petkov wrote:
>On Sun, Apr 14, 2013 at 10:41:07AM +0300, Gleb Natapov wrote:
>> Currently userspace a
That is what I mean yes...
Borislav Petkov wrote:
>On Sun, Apr 14, 2013 at 11:36:29AM -0700, H. Peter Anvin wrote:
>> Just to interject here... all this is about host kernel vs userspace,
>> correct? I.e. nothing that affects the guest. I assume that the guest
>> sees CPUI
Note that "Atom" isn't a CPU but a line of CPUs. Sadly Qemu's N270 model is
broken.
Borislav Petkov wrote:
>On Tue, Apr 16, 2013 at 01:47:46PM +0200, Paolo Bonzini wrote:
>> Atom is not defined by QEMU;
>
>$ qemu-system-x86_64 -cpu ?
>
>...
>
>x86 n270 Intel(R) Atom(TM) CPU N270
On 04/23/2013 04:41 PM, Borislav Petkov wrote:
>
> Btw, in thinking about this more, I'm kinda sceptical we want to use the
> CPUID layout for this new KVM_GET_EMULATED_* ioctl. And the reason why
> I'm sceptical is that not every instruction is behind a CPUID capability
> bit and if we want to te
On 04/29/2013 07:48 AM, Don Dutile wrote:
>
> c) it's architecture neutral, or can be made architecture neutral.
>e.g., inb/outb & PCI ioport support is very different btwn x86 &
> non-x86.
>A hypercall interface would not have that dependency/difference.
>
You are joking, right? Hyper
On 06/05/2013 09:20 AM, Michael S. Tsirkin wrote:
>
> Spec says IO and memory can be enabled/disabled, separately.
> PCI Express spec says devices should work without IO.
>
For "native endpoints". Currently virtio would be a "legacy endpoint"
which is quite correct -- it is compatible with a le
On 06/05/2013 01:45 PM, Anthony Liguori wrote:
>
> But if you want to boot from the 16th device, the BIOS needs to solve
> this problem anyway.
>
No. Just have the BIOS plumb the path to the device it wants to boot
from. Problem solved.
-hpa
--
To unsubscribe from this list: send th
On 06/05/2013 02:50 PM, Anthony Liguori wrote:
> "H. Peter Anvin" writes:
>
>> On 06/05/2013 09:20 AM, Michael S. Tsirkin wrote:
>>>
>>> Spec says IO and memory can be enabled/disabled, separately.
>>> PCI Express spec says devices should
On 06/05/2013 03:08 PM, Anthony Liguori wrote:
>>
>> Definitely an option. However, we want to be able to boot from native
>> devices, too, so having an I/O BAR (which would not be used by the OS
>> driver) should still at the very least be an option.
>
> What makes it so difficult to work with a
On 06/05/2013 11:34 PM, Gleb Natapov wrote:
>>
>> SeaBIOS runs the virtio code in 32-bit mode with a flat memory layout.
>> There are loads of ASSERT32FLAT()s in the code to make sure of this.
>>
> Well, not exactly. Initialization is done in 32bit, but disk
> reads/writes are done in 16bit mode si
On 06/06/2013 08:10 AM, Gleb Natapov wrote:
> On Thu, Jun 06, 2013 at 05:06:32PM +0200, Gerd Hoffmann wrote:
>>
> Isn't this approach broken? How can SeaBIOS be sure it restores real
> mode registers to exactly same state they were before entering 32bit
> mode?
>
It can't... so yes, it is broken.
On 07/19/2013 05:10 AM, Paolo Bonzini wrote:
>> +
>> +static inline bool kvm_para_available(void)
>> +{
>> if (boot_cpu_data.cpuid_level < 0)
>> return false; /* So we don't blow up on old processors */
>>
>> if (cpu_has_hypervisor) {
>> -cpuid(KVM_CPUID_SIGNA
On 07/19/2013 02:00 PM, Paolo Bonzini wrote:
> Il 19/07/2013 22:59, H. Peter Anvin ha scritto:
>>>>>> -cpuid(KVM_CPUID_SIGNATURE, &eax, &ebx, &ecx, &edx);
>>>>>> -memcpy(signature + 0, &ebx
On 07/23/2013 02:41 AM, Jason Wang wrote:
>
> +static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t
> leaves)
> +{
> + uint32_t base, eax, ebx, ecx, edx;
> + char signature[13];
> +
> + for (base = 0x4000; base < 0x4001; base += 0x100) {
> + cpui
On 07/23/2013 06:55 AM, KY Srinivasan wrote:
>
> This strategy of hypervisor detection based on some detection order IMHO is
> not
> a robust detection strategy. The current scheme works since the only
> hypervisor emulated
> (by other hypervisors happens to be Hyper-V). What if this were to cha
On 07/23/2013 04:16 AM, Paolo Bonzini wrote:
>
> That's nicer, though strcmp is what the replaced code used to do in
> patches 2 and 3.
>
> Note that memcmp requires the caller to use "KVMKVMKVM\0\0" as the
> signature (or alternatively hypervisor_cpuid_base can copy the argument
> into another 1
On 07/23/2013 10:45 AM, KY Srinivasan wrote:
>>
>> One strategy would be to pick the *last* one in the CPUID list, since
>> the ones before it are logically the one(s) being emulated...
>
> Is it always possible to guarantee this ordering. As a hypothetical, what if
> hypervisor A
> emulates Hype
On 07/23/2013 09:44 PM, Jason Wang wrote:
>
> Since it's just a minor optimization. How about just keep using the
> strcmp()?
>
It's more that it enables the rest of the cleanup, making the code
easier to read.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
t
On 07/23/2013 09:37 PM, Jason Wang wrote:
> On 07/23/2013 10:48 PM, H. Peter Anvin wrote:
>> On 07/23/2013 06:55 AM, KY Srinivasan wrote:
>>> This strategy of hypervisor detection based on some detection order IMHO is
>>> not
>>> a robust detection strategy
I don't see how this solves the A emulates B, B emulates A problem?
KY Srinivasan wrote:
>
>
>> -Original Message-
>> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of
>Paolo
>> Bonzini
>> Sent: Wednesday, July 24, 2013 3:07 AM
>&
What I'm suggesting is exactly that except that the native hypervisor is later
in CPUID space.
KY Srinivasan wrote:
>
>
>> -Original Message-
>> From: H. Peter Anvin [mailto:h...@zytor.com]
>> Sent: Wednesday, July 24, 2013 11:14 AM
>> To: KY Srinivas
On 08/05/2013 07:34 AM, Konrad Rzeszutek Wilk wrote:
>
> Could you provide me with a git branch so I can test it overnight please?
>
Pull tip:x86/paravirt.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More
So, having read through the entire thread I *think* this is what the
status of this patchset is:
1. Patches 1-17 are noncontroversial, Raghavendra is going to send an
update split into two patchsets;
2. There are at least two versions of patch 15; I think the "PATCH
RESEND RFC" is the right
On 08/06/2013 04:40 AM, Raghavendra K T wrote:
> This series replaces the existing paravirtualized spinlock mechanism
> with a paravirtualized ticketlock mechanism. The series provides
> implementation for both Xen and KVM.
>
> The current set of patches are for Xen/x86 spinlock/KVM guest side, to
On 08/06/2013 07:54 PM, Raghavendra K T wrote:
> On 08/07/2013 02:31 AM, H. Peter Anvin wrote:
>>
>> What is the baseline for this patchset? I tried to apply it on top of
>> 3.11-rc4 and I got nontrivial conflicts.
>>
>
> I had based it on top of 445363e8 [ Mer
On 08/07/2013 06:02 PM, Gleb Natapov wrote:
> On Wed, Aug 07, 2013 at 08:50:12PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Wed, Aug 07, 2013 at 12:15:21PM +0530, Raghavendra K T wrote:
>>> On 08/07/2013 10:18 AM, H. Peter Anvin wrote:
>>>>> Please let
On 08/08/2013 02:13 PM, H. Peter Anvin wrote:
> On 08/07/2013 06:02 PM, Gleb Natapov wrote:
>> On Wed, Aug 07, 2013 at 08:50:12PM -0400, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Aug 07, 2013 at 12:15:21PM +0530, Raghavendra K T wrote:
>>>> On 08/07/2013
The kbuild test bot is reporting some pretty serious errors for this
patchset. I think these are serious enough that the patchset will need
to be respun.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majo
On 08/09/2013 06:00 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Aug 09, 2013 at 06:20:02PM +0530, Raghavendra K T wrote:
>> On 08/09/2013 04:34 AM, H. Peter Anvin wrote:
>>>
>>> Okay, I figured it out.
>>>
>>> One of several problems with the formatting
Raghavendra...
Even with this latest patch this branch is broken:
:(.discard+0x6108): multiple definition of `__pcpu_unique_lock_waiting'
arch/x86/xen/built-in.o:(.discard+0x23): first defined here
CC drivers/firmware/google/gsmi.o
arch/x86/kernel/built-in.o:(.discard+0x6108): multiple def
On 07/16/2014 07:07 AM, Andy Lutomirski wrote:
>
> This patch has nothing whatsoever to do with how much I trust the CPU
> vs the hypervisor. It's for the enormous installed base of machines
> without RDRAND.
>
> hpa suggested emulating RDRAND awhile ago, but I think that'll
> unusably slow -- t
On 07/16/2014 09:08 AM, Paolo Bonzini wrote:
> Il 16/07/2014 18:03, H. Peter Anvin ha scritto:
>> I suggested emulating RDRAND *but not set the CPUID bit*. We already
>> developed a protocol in KVM/Qemu to enumerate emulated features (created
>> for MOVBE as I recall), specif
On 07/16/2014 09:21 AM, Gleb Natapov wrote:
> On Wed, Jul 16, 2014 at 09:13:23AM -0700, H. Peter Anvin wrote:
>> On 07/16/2014 09:08 AM, Paolo Bonzini wrote:
>>> Il 16/07/2014 18:03, H. Peter Anvin ha scritto:
>>>> I suggested emulating RDRAND *but not s
On 07/16/2014 02:32 PM, Andy Lutomirski wrote:
>
> On the theory that I see no legitimate reason to expose this to guest
> user space, I think we shouldn't expose it. If we wanted to add a
> get_random_bytes syscall, that would be an entirely different story,
> though.
>
> Should I send v3 as on
On 07/16/2014 02:45 PM, Andy Lutomirski wrote:
> diff --git a/arch/x86/include/asm/archslowrng.h
> b/arch/x86/include/asm/archslowrng.h
> new file mode 100644
> index 000..c8e8d0d
> --- /dev/null
> +++ b/arch/x86/include/asm/archslowrng.h
> @@ -0,0 +1,30 @@
> +/*
> + * This file is part of the
On 07/16/2014 03:40 PM, Andy Lutomirski wrote:
> On Wed, Jul 16, 2014 at 3:13 PM, Andy Lutomirski wrote:
>> My personal preference is to defer this until some user shows up. I
>> think that even this would be too complicated for KASLR, which is the
>> only extremely early-boot user that I found.
On 07/16/2014 05:03 PM, Andy Lutomirski wrote:
>>
>> prandom is exactly the opposite; it is designed for when we need
>> possibly low quality random numbers very quickly. RDRAND is actually
>> too slow.
>
> I meant that prandom isn't using rdrand for early seeding.
>
We should probably fix that
On 07/17/2014 03:33 AM, Theodore Ts'o wrote:
> On Wed, Jul 16, 2014 at 09:55:15PM -0700, H. Peter Anvin wrote:
>> On 07/16/2014 05:03 PM, Andy Lutomirski wrote:
>>>>
>>> I meant that prandom isn't using rdrand for early seeding.
>>>
>>
&
On 07/22/2014 01:44 PM, Andy Lutomirski wrote:
>
> But, if you Intel's hardware does, in fact, work as documented, then
> the current code will collect very little entropy on RDSEED-less
> hardware. I see no great reason that we should do something weaker
> than following Intel's explicit recomme
On 07/22/2014 02:04 PM, Andy Lutomirski wrote:
>
> Just to check: do you mean the RDRAND is very likely to work (i.e.
> arch_get_random_long will return true) or that RDRAND will actually
> reseed several times during initialization?
>
I mean that RDRAND will actually reseed several times during
On 07/22/2014 02:10 PM, Andy Lutomirski wrote:
> On Tue, Jul 22, 2014 at 2:08 PM, H. Peter Anvin wrote:
>> On 07/22/2014 02:04 PM, Andy Lutomirski wrote:
>>>
>>> Just to check: do you mean the RDRAND is very likely to work (i.e.
>>> arch_get_random_long w
On 08/11/2014 11:49 AM, Amit Shah wrote:
> The khwrngd thread is started when a hwrng device of sufficient
> quality is registered. The virtio-rng device is backed by the
> hypervisor, and we trust the hypervisor to provide real entropy. A
> malicious hypervisor is a scenario that's ruled out, so
On 08/11/2014 10:27 PM, Amit Shah wrote:
> On (Mon) 11 Aug 2014 [15:11:03], H. Peter Anvin wrote:
>> On 08/11/2014 11:49 AM, Amit Shah wrote:
>>> The khwrngd thread is started when a hwrng device of sufficient
>>> quality is registered. The virtio-rng device is backed
On 08/12/2014 12:22 PM, Andy Lutomirski wrote:
> On Tue, Aug 12, 2014 at 12:17 PM, Theodore Ts'o wrote:
>> On Tue, Aug 12, 2014 at 12:11:29PM -0700, Andy Lutomirski wrote:
>>>
>>> What's the status of this series? I assume that it's too late for at
>>> least patches 2-5 to make it into 3.17.
>>
>
On 08/13/2014 09:13 AM, Andy Lutomirski wrote:
>
> Sounds good to me.
>
> FWIW, I'd like to see a second use added in random.c: I think that we
> should do this, or even all of init_std_data, on resume from suspend
> and especially on resume from hibernate / kexec.
>
Yes, we should. We also ne
On 08/13/2014 11:33 AM, Andy Lutomirski wrote:
>
> As for doing arch_random_init after clone/migration, I think we'll
> need another KVM extension for that, since, AFAIK, we don't actually
> get notified that we were cloned or migrated. That will be
> nontrivial. Maybe we can figure that out at
On 08/13/2014 11:44 AM, H. Peter Anvin wrote:
> On 08/13/2014 11:33 AM, Andy Lutomirski wrote:
>>
>> As for doing arch_random_init after clone/migration, I think we'll
>> need another KVM extension for that, since, AFAIK, we don't actually
>> get notified t
On 08/27/2014 12:00 AM, Paolo Bonzini wrote:
> Il 27/08/2014 01:58, Andy Lutomirski ha scritto:
>> hpa pointed out that the ABI that I chose (an MSR from the KVM range
>> and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice
>> to allocate an MSR that everyone involved can agree on
On 09/18/2014 07:40 AM, KY Srinivasan wrote:
>>
>> The main questions are what MSR index to use and how to detect the
>> presence of the MSR. I've played with two approaches:
>>
>> 1. Use CPUID to detect the presence of this feature. This is very easy for
>> KVM to implement by using a KVM-specif
y, September 18, 2014 10:18 AM
>>>> To: Nakajima, Jun; KY Srinivasan
>>>> Cc: Mathew John; Theodore Ts'o; John Starks; kvm list; Gleb
>Natapov; Niels
>>>> Ferguson; Andy Lutomirski; David Hepkin; H. Peter Anvin; Jake
>Oshins; Linux
>>>>
On 09/18/2014 02:46 PM, David Hepkin wrote:
> I'm not sure what you mean by "this mechanism?" Are you suggesting that each
> hypervisor put "CrossHVPara\0" somewhere in the 0x4000 - 0x400f CPUID
> range, and an OS has to do a full scan of this CPUID range on boot to find
> it? That see
On 09/18/2014 03:00 PM, Andy Lutomirski wrote:
> On Thu, Sep 18, 2014 at 2:46 PM, David Hepkin wrote:
>> I'm not sure what you mean by "this mechanism?" Are you suggesting that
>> each hypervisor put "CrossHVPara\0" somewhere in the 0x4000 - 0x400f
>> CPUID range, and an OS has to do 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 majord...@vger.ker
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
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 eno
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 Na
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 Na
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 t
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.
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 b
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 b
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
On 09/22/2014 06:31 AM, Christopher Covington wrote:
> On 09/19/2014 05:46 PM, H. Peter Anvin wrote:
>> 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 RD
1 - 100 of 264 matches
Mail list logo
