On Tue, Aug 12, 2014 at 06:27:11PM -0700, Mario Smarduch wrote:
> On 08/12/2014 02:50 AM, Christoffer Dall wrote:
> > On Mon, Aug 11, 2014 at 06:25:05PM -0700, Mario Smarduch wrote:
> >> On 08/11/2014 12:13 PM, Christoffer Dall wrote:
> >>> On Thu, Jul 24, 2014 at 05:56:08PM -0700, Mario Smarduch w
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 Aug 13, 2014 12:48 AM, "H. Peter Anvin" wrote:
>
> 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 t
On Tue, Aug 12, 2014 at 6:47 PM, Nikolay Nikolaev
wrote:
>
> Hello,
>
>
> On Tue, Aug 12, 2014 at 5:41 AM, Li Liu wrote:
> >
> > Hi all,
> >
> > Is anyone there can tell the current status of vhost-net on kvm-arm?
> >
> > Half a year has passed from Isa Ansharullah asked this question:
> > http:/
This patch emulates debug registers and debug exception
to support guest using debug resource. This enables running
gdb/kgdb etc in guest.
On BOOKE architecture we cannot share debug resources between QEMU and
guest because:
When QEMU is using debug resources then debug exception must
be a
This was missed in respective one_reg implementation patch.
Signed-off-by: Bharat Bhushan
---
Documentation/virtual/kvm/api.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index a21ff22..9177f23 100644
--- a/Documen
From: Yang Zhang
Guest may mask the IOAPIC entry before issue EOI. In such case,
EOI will not be intercepted by hypervisor due to the corrensponding
bit in eoi exit bitmap is not setting.
The solution is to check ISR + TMR to construct the EOI exit bitmap.
This patch is a better fixing for the
This patch introduced the API to return device tree info about
a PLATFORM device (if described by a device tree) and the skeleton
of the implementation for VFIO_PLATFORM. Information about any device
node bound by VFIO_PLATFORM should be queried via the introduced ioctl
VFIO_DEVICE_GET_DEVTREE_INFO
This RFC's intention is to show what an interface to access device node
properties for VFIO_PLATFORM can look like.
If a device tree node corresponding to a platform device bound by VFIO_PLATFORM
is available, this patch series will allow the user to query the properties
associated with this devic
Certain properties of a device tree node are accessible as an array
of unsigned integers, either u32, u16, or u8. Let the VFIO user query
this type of device node properties.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/devtree.c | 99 +
1 fil
Certain device tree properties (e.g. the device node name, the compatible
string), are available as a list of strings (separated by the null
terminating character). Let the VFIO user query this type of properties.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/devtree.c | 60 +
For various reasons, the available properties of the platform device
node in the device tree node should be referred to by the property name.
Passing type = VFIO_DEVTREE_PROP_NAMES to VFIO_DEVICE_GET_DEVTREE_INFO,
returns a list of strings with the available properties that the VFIO
user can access
On 2014/8/13 17:10, Nikolay Nikolaev wrote:
> On Tue, Aug 12, 2014 at 6:47 PM, Nikolay Nikolaev
> wrote:
>>
>> Hello,
>>
>>
>> On Tue, Aug 12, 2014 at 5:41 AM, Li Liu wrote:
>>>
>>> Hi all,
>>>
>>> Is anyone there can tell the current status of vhost-net on kvm-arm?
>>>
>>> Half a year has pass
This is a test case complementing the patch series:
[RFC 0/4] VFIO: PLATFORM: Return device tree info for a platform device node
This test case is based on the ARM PL330 DMA controller and shows how device
node properties can be accessed from userspace.
It doesn't apply on anything in particular,
On Wed, Aug 13, 2014 at 12:10 PM, Nikolay Nikolaev
wrote:
> On Tue, Aug 12, 2014 at 6:47 PM, Nikolay Nikolaev
> wrote:
>>
>> Hello,
>>
>>
>> On Tue, Aug 12, 2014 at 5:41 AM, Li Liu wrote:
>> >
>> > Hi all,
>> >
>> > Is anyone there can tell the current status of vhost-net on kvm-arm?
>> >
>> > H
On Tue, Aug 12, 2014 at 06:05:21PM +0200, Christoffer Dall wrote:
> On Mon, Aug 11, 2014 at 03:38:23PM -0500, 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
Alexey Kardashevskiy writes:
> fc95ca7284bc54953165cba76c3228bd2cdb9591 claims that there is no
> functional change but this is not true as it calls get_order() (which
> takes bytes) where it should have called ilog2() and the kernel stops
> on VM_BUG_ON().
>
> This replaces get_order() with ilog
On Tue, Aug 12, 2014 at 01:57:05PM +0300, Razya Ladelsky wrote:
> "Michael S. Tsirkin" wrote on 12/08/2014 12:18:50 PM:
>
> > From: "Michael S. Tsirkin"
> > To: David Miller
> > Cc: Razya Ladelsky/Haifa/IBM@IBMIL, kvm@vger.kernel.org, Alex
> > Glikson/Haifa/IBM@IBMIL, Eran Raichstein/Haifa/IBM
Il 12/08/2014 21:29, Eduardo Habkost ha scritto:
> On Tue, Aug 12, 2014 at 09:12:00PM +0200, Paolo Bonzini wrote:
>> Il 12/08/2014 20:55, Eduardo Habkost ha scritto:
>>> This makes the CPUID data change under the guest's feet during
>>> live-migration.
>>>
>>> Adding compat code to ensure older mac
Commit d40a6898e5 mistakenly caused instructions which are not marked as
EmulateOnUD to be emulated upon #UD exception. The commit caused the check of
whether the instruction flags include EmulateOnUD to never be evaluated. As a
result instructions whose emulation is broken may be emulated. This f
On Aug 13, 2014, at 8:33 PM, Christoffer Dall wrote:
> On Tue, Aug 12, 2014 at 06:05:21PM +0200, Christoffer Dall wrote:
>> On Mon, Aug 11, 2014 at 03:38:23PM -0500, Joel Schopp wrote:
>>> The current VTTBR_BADDR_MASK only masks 39 bits, which is broken on current
>>> systems. Rather than just add
Correction: the word “never” in the message is too harsh.
Nonetheless, there is a regression bug. I encountered it with “wrfsbase”
instruction.
Nadav
On Aug 13, 2014, at 4:50 PM, Nadav Amit wrote:
> Commit d40a6898e5 mistakenly caused instructions which are not marked as
> EmulateOnUD to be em
On Wed, Aug 13, 2014 at 12:48:41AM -0700, H. Peter Anvin wrote:
> The proposed arch_get_rng_seed() is not really what it claims to be; it
> most definitely does not produce seed-grade randomness, instead it seems
> to be an arch function for best-effort initialization of the entropy
> pools -- whic
unsubscribe kvm udesh...@binghamton.edu
--
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 http://vger.kernel.org/majordomo-info.html
On Mon, Aug 04, 2014 at 02:08:22PM +0200, Eric Auger wrote:
> This patch enables irqfd on ARM.
>
> irqfd framework enables to inject a virtual IRQ into a guest upon an
> eventfd trigger. User-side uses KVM_IRQFD VM ioctl to provide KVM with
> a kvm_irqfd struct that associates a VM, an eventfd, an
Hi Linus,
The following changes since commit 7f0d32e0c1a7a23216a0f2694ec841f60e9dddfd:
Merge tag 'microblaze-3.17-rc1' of git://git.monstr.eu/linux-2.6-microblaze
(2014-08-07 09:02:26 -0700)
are available in the git repository at:
git://github.com/awilliam/linux-vfio.git tags/vfio-v3.17-r
Current KVM only supports RDMSR for K7_EVNTSEL0 and K7_EVNTSEL0
MSRs. Reading the rest MSRs will trigger KVM to inject #GP into
guest VM. This causes a warning message "Failed to access perfctr
msr (MSR c0010001 is )" on AMD host. This patch
adds RDMSR support for all K7_EVNTSELn an
Wrong one, sorry. Please discard this one. Updated one will follow.
-Wei
On 08/13/2014 10:58 AM, Wei Huang wrote:
Current KVM only supports RDMSR for K7_EVNTSEL0 and K7_EVNTSEL0
MSRs. Reading the rest MSRs will trigger KVM to inject #GP into
guest VM. This causes a warning message "Failed to ac
Current KVM only supports RDMSR for K7_EVNTSEL0 and K7_PERFCTR0
MSRs. Reading the rest MSRs will trigger KVM to inject #GP into
guest VM. This causes a warning message "Failed to access perfctr
msr (MSR c0010001 is )" on AMD host. This patch
adds RDMSR support for all K7_EVNTSELn an
On Wed, Aug 13, 2014 at 7:32 AM, Theodore Ts'o wrote:
> On Wed, Aug 13, 2014 at 12:48:41AM -0700, H. Peter Anvin wrote:
>> The proposed arch_get_rng_seed() is not really what it claims to be; it
>> most definitely does not produce seed-grade randomness, instead it seems
>> to be an arch function f
Commit 5045b46803 added a check that cs.dpl equals cs.rpl during
task-switch. Unfortunately, is causes some of my tests that run well on
bare-metal to fail.
Although this check is mentioned in table 7-1 of the SDM as causing a
#TSS exception, it is not mentioned in table 6-6 that lists "invalid TS
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 Wed, Aug 13, 2014 at 10:45:25AM -0700, H. Peter Anvin wrote:
> 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
> > an
On Wed, Aug 13, 2014 at 11:22 AM, Theodore Ts'o wrote:
> On Wed, Aug 13, 2014 at 10:45:25AM -0700, H. Peter Anvin wrote:
>> 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 thi
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
The SDM specifies (June 2014 Vol3 11.11.5):
On a hardware reset, the P6 and more recent processors clear the
valid flags in variable-range MTRRs and clear the E flag in the
IA32_MTRR_DEF_TYPE MSR to disable all MTRRs. All other bits in the
MTRRs are undefined.
We currently do none
a number of comments -- feel free to address or ignore each as you see fit:
On 08/13/14 21:09, Alex Williamson wrote:
> The SDM specifies (June 2014 Vol3 11.11.5):
>
> On a hardware reset, the P6 and more recent processors clear the
> valid flags in variable-range MTRRs and clear the E fl
Hello,
I am exploring ideas for clients in cloud to be able to implement functions
where there could verify the services offered by the cloud provider like
metering services.
Idea is I am using the concept of write execute protection scheme. And also I
am using TamperEvident Log. I am making u
Hello,
I am working on testbed executing some secure applications on untrusted
hypervisor (in my case kvm).
In order to verify the run time integrity of applications,I am using an idea
based on write xor execute protection protecting any of the page table
updates of hypervisor&user code/data u
On Wed, 2014-08-13 at 22:33 +0200, Laszlo Ersek wrote:
> a number of comments -- feel free to address or ignore each as you see fit:
>
> On 08/13/14 21:09, Alex Williamson wrote:
> > The SDM specifies (June 2014 Vol3 11.11.5):
> >
> > On a hardware reset, the P6 and more recent processors cle
On 08/14/14 00:06, Alex Williamson wrote:
> On Wed, 2014-08-13 at 22:33 +0200, Laszlo Ersek wrote:
>> a number of comments -- feel free to address or ignore each as you see fit:
>>
>> On 08/13/14 21:09, Alex Williamson wrote:
>>> mappings which are now stale after reset. The result is that OVMF
>
Hi Wei,
On Thu, Aug 14, 2014 at 03:16:25AM +0800, Wei Wang wrote:
>From: Yang Zhang
>
>Guest may mask the IOAPIC entry before issue EOI. In such case,
>EOI will not be intercepted by hypervisor due to the corrensponding
>bit in eoi exit bitmap is not setting.
>
>The solution is to check ISR + TMR
On 08/14/14 01:17, Laszlo Ersek wrote:
> - With KVM, the lack of loading MTRR state from KVM, combined with the
> (partial) storing of MTRR state to KVM, has two consequences:
> - migration invalidates (loses) MTRR state,
I'll concede that migration *already* loses MTRR state (on KVM), even
b
On 08/13/2014 12:30 AM, Christoffer Dall wrote:
> On Tue, Aug 12, 2014 at 06:27:11PM -0700, Mario Smarduch wrote:
>> On 08/12/2014 02:50 AM, Christoffer Dall wrote:
>>> On Mon, Aug 11, 2014 at 06:25:05PM -0700, Mario Smarduch wrote:
On 08/11/2014 12:13 PM, Christoffer Dall wrote:
> On Thu,
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 that we were cloned or migrated. That will
On 2014/8/13 19:25, Nikolay Nikolaev wrote:
> On Wed, Aug 13, 2014 at 12:10 PM, Nikolay Nikolaev
> wrote:
>> On Tue, Aug 12, 2014 at 6:47 PM, Nikolay Nikolaev
>> wrote:
>>>
>>> Hello,
>>>
>>>
>>> On Tue, Aug 12, 2014 at 5:41 AM, Li Liu wrote:
Hi all,
Is anyone there can tel
fc95ca7284bc54953165cba76c3228bd2cdb9591 claims that there is no
functional change but this is not true as it calls get_order() (which
takes bytes) where it should have called ilog2() and the kernel stops
on VM_BUG_ON().
This replaces get_order() with order_base_2() (round-up version of ilog2).
S
Alexey Kardashevskiy writes:
> fc95ca7284bc54953165cba76c3228bd2cdb9591 claims that there is no
> functional change but this is not true as it calls get_order() (which
> takes bytes) where it should have called ilog2() and the kernel stops
> on VM_BUG_ON().
>
> This replaces get_order() with orde
On Wed, Aug 13, 2014 at 7:41 PM, H. Peter Anvin wrote:
> 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 actual
On 08/13/2014 05:18 AM, David Matlack wrote:
> On Mon, Aug 11, 2014 at 10:02 PM, Xiao Guangrong
> wrote:
>> @@ -722,9 +719,10 @@ static struct kvm_memslots *install_new_memslots(struct
>> kvm *kvm,
>> {
>> struct kvm_memslots *old_memslots = kvm->memslots;
>>
>
> I think you want
>
>
This introduces and uses a very simple synchronous mechanism to get
/dev/urandom-style bits appropriate for initial KVM PV guest RNG
seeding.
It also re-works the way that architectural random data is fed into
random.c's pools. Timekeeping randomness now comes directly from
the timekeeping core r
It's considerably better than any of the alternatives on KVM.
Rather than reinventing all of the cpu feature query code, this fixes
native_cpuid to work in PIC objects.
I haven't combined it with boot/cpuflags.c's cpuid implementation:
including asm/processor.h from boot/cpuflags.c results in a f
This is a straightforward implementation: for each bit of internal
RNG state, request one bit from KVM_GET_RNG_SEED. This is done even
if RDSEED/RDRAND worked, since KVM_GET_RNG_SEED is likely to provide
cryptographically secure output even if the CPU's RNG is weak or
compromised.
Acked-by: Paolo
This is a straightforward implementation: for each bit of internal
RNG state, request one bit from KVM_GET_RNG_SEED. This is done even
if RDSEED/RDRAND worked, since KVM_GET_RNG_SEED is likely to provide
cryptographically secure output even if the CPU's RNG is weak or
compromised.
Acked-by: Paolo
This does the same thing as the generic implementation, except
that it logs how many bits of each type it collected. I want to
know whether the initial seeding is working and, if so, whether
the RNG is fast enough.
(I know that hpa assures me that the hardware RNG is more than
fast enough, but I
After a suspend/resume cycle, and especially after hibernating, we
should assume that the random pools might have leaked. To minimize
the risk this poses, try to collect fresh architectural entropy on
resume.
Signed-off-by: Andy Lutomirski
---
drivers/char/random.c | 26 +++-
This adds a simple interface to allow a guest to request 64 bits of
host nonblocking entropy. This is independent of virtio-rng for a
couple of reasons:
- It's intended to be usable during early boot, when a trivial
synchronous interface is needed.
- virtio-rng gives blocking entropy, and m
Currently, init_std_data calls ktime_get_real(). This imposes
awkward constraints on when init_std_data can be called, and
init_std_data is unlikely to collect the full unpredictable data
available to the timekeeping code, especially after resume.
Remove this code from random.c and add the approp
Currently, init_std_data contains its own logic for using arch
random sources. This replaces that logic with a generic function
arch_rng_init that allows arch code to supply its own logic. The
default implementation tries arch_get_random_seed_long and
arch_get_random_long individually.
The only
59 matches
Mail list logo
