From: David Matlack dmatl...@google.com
The following events can lead to an incorrect KVM_EXIT_MMIO bubbling
up to userspace:
(1) Guest accesses gpa X without a memory slot. The gfn is cached in
struct kvm_vcpu_arch (mmio_gfn). On Intel EPT-enabled hosts, KVM sets
the SPTE write-execute-noread
We may cache the current mmio generation number and stale memslot info
into spte, like this scenarioļ¼
CPU 0 CPU 1
page fault:add a new memslot
read memslot and detecting its a mmio access
Sorry, the title is not clear enough.
This is the v2 which fixes the issue pointed out by David:
the generation number actually decreases.
Please review.
On 08/14/2014 03:01 PM, Xiao Guangrong wrote:
We may cache the current mmio generation number and stale memslot info
into spte, like this
Hi, all
I'm using VFIO to assign intel 82599 VF to VM, now I encounter a problem,
82599 PF and its VFs belong to the same iommu_group, but I only want to assign
some VFs to one VM, and some other VFs to another VM, ...,
so how to only unbind (part of) the VFs but PF?
I read the kernel doc
On 08/07/2014 08:47 PM, Zhangjie (HZ) wrote:
On 2014/8/5 20:14, Zhangjie (HZ) wrote:
On 2014/8/5 17:49, Michael S. Tsirkin wrote:
On Tue, Aug 05, 2014 at 02:29:28PM +0800, Zhangjie (HZ) wrote:
Jason is right, the new order is not the cause of network unreachable.
Changing order seems not
On Thu, Aug 14, 2014 at 04:52:40PM +0800, Jason Wang wrote:
On 08/07/2014 08:47 PM, Zhangjie (HZ) wrote:
On 2014/8/5 20:14, Zhangjie (HZ) wrote:
On 2014/8/5 17:49, Michael S. Tsirkin wrote:
On Tue, Aug 05, 2014 at 02:29:28PM +0800, Zhangjie (HZ) wrote:
Jason is right, the new order is not
Top of the day to you all from the Head Quarter Western Union and Money
Gram Transfer.
Dear User
This is to inform all our users that the high rate of scam has been coming
so much and we are receive complains from beach Transfer office that our
customer has been send money to differed country as
On Thu, 2014-08-14 at 16:22 +0800, Zhang Haoyu wrote:
Hi, all
I'm using VFIO to assign intel 82599 VF to VM, now I encounter a problem,
82599 PF and its VFs belong to the same iommu_group, but I only want to
assign some VFs to one VM, and some other VFs to another VM, ...,
so how to only
On 14.08.14 07:13, Aneesh Kumar K.V wrote:
Alexey Kardashevskiy a...@ozlabs.ru 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 Thu, 2014-08-14 at 01:44 +0200, Laszlo Ersek wrote:
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
On Thu, Jul 10 2014 at 3:42:31 pm BST, Christoffer Dall
christoffer.d...@linaro.org wrote:
When userspace loads code and data in a read-only memory regions, KVM
needs to be able to handle this on arm and arm64. Specifically this is
used when running code directly from a read-only flash
we at Virtual Open Systems did some work and tested vhost-net on ARM
back in March.
The setup was based on:
- host kernel with our ioeventfd patches:
http://www.spinics.net/lists/kvm-arm/msg08413.html
- qemu with the aforementioned patches from Ying-Shiuan Pan
On Thu, Aug 14, 2014 at 12:01 AM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
From: David Matlack dmatl...@google.com
The following events can lead to an incorrect KVM_EXIT_MMIO bubbling
up to userspace:
(1) Guest accesses gpa X without a memory slot. The gfn is cached in
struct
On Wed, Aug 13, 2014 at 10:43 PM, Andy Lutomirski l...@amacapital.net wrote:
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
It turns out that not only do we not follow the SDM guidelines for
reseting MTRR state on vCPU reset, but we really don't even attempt
to keep KVM MTRR state synchronized with QEMU, which affects not
only reset, but migration. This series implements the get/put MSR
support for KVM, then goes on
We currently define the number of variable range MTRR registers as 8
in the CPUX86State structure and vmstate, but use MSR_MTRRcap_VCNT
(also 8) to report to guests the number available. Change this to
use MSR_MTRRcap_VCNT consistently.
Signed-off-by: Alex Williamson alex.william...@redhat.com
The MTRR state in KVM currently runs completely independent of the
QEMU state in CPUX86State.mtrr_*. This means that on migration, the
target loses MTRR state from the source. Generally that's ok though
because KVM ignores it and maps everything as write-back anyway. The
exception to this rule
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
On 08/14/14 21:24, Alex Williamson wrote:
We currently define the number of variable range MTRR registers as 8
in the CPUX86State structure and vmstate, but use MSR_MTRRcap_VCNT
(also 8) to report to guests the number available. Change this to
use MSR_MTRRcap_VCNT consistently.
In the check_counters_many function measure was only being called on the last
counter, causing the pmu test to fail. This ensures that measure is called for
each counter in the array before calling verify_counter.
Signed-off-by: Chris J Arges chris.j.ar...@canonical.com
---
x86/pmu.c | 6 +++---
You're going to use my name in contexts that I won't wish to be privy
to. :) I like everything about this patch except:
On 08/14/14 21:24, Alex Williamson wrote:
The MTRR state in KVM currently runs completely independent of the
QEMU state in CPUX86State.mtrr_*. This means that on migration,
On 08/14/14 21:24, 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 flag in the
IA32_MTRR_DEF_TYPE MSR to disable all MTRRs. All other bits in
On 08/14/14 21:24, Alex Williamson wrote:
The MTRR state in KVM currently runs completely independent of the
QEMU state in CPUX86State.mtrr_*. This means that on migration, the
target loses MTRR state from the source. Generally that's ok though
because KVM ignores it and maps everything as
On Thu, 2014-08-14 at 23:20 +0200, Laszlo Ersek wrote:
You're going to use my name in contexts that I won't wish to be privy
to. :) I like everything about this patch except:
+case MSR_MTRRphysBase(0) ... MSR_MTRRphysMask(MSR_MTRRcap_VCNT):
... the off-by-one in this case range.
v3:
- Fix off-by-one identified by Laszlo in 2/3
- Add R-b in 1 3
It turns out that not only do we not follow the SDM guidelines for
reseting MTRR state on vCPU reset, but we really don't even attempt
to keep KVM MTRR state synchronized with QEMU, which affects not
only reset, but migration.
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
The MTRR state in KVM currently runs completely independent of the
QEMU state in CPUX86State.mtrr_*. This means that on migration, the
target loses MTRR state from the source. Generally that's ok though
because KVM ignores it and maps everything as write-back anyway. The
exception to this rule
We currently define the number of variable range MTRR registers as 8
in the CPUX86State structure and vmstate, but use MSR_MTRRcap_VCNT
(also 8) to report to guests the number available. Change this to
use MSR_MTRRcap_VCNT consistently.
Signed-off-by: Alex Williamson alex.william...@redhat.com
On 08/14/14 23:39, Alex Williamson wrote:
The MTRR state in KVM currently runs completely independent of the
QEMU state in CPUX86State.mtrr_*. This means that on migration, the
target loses MTRR state from the source. Generally that's ok though
because KVM ignores it and maps everything as
On 08/13/2014 06:20 PM, Mario Smarduch wrote:
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,
On 08/14/2014 06:02 PM, Michael S. Tsirkin wrote:
On Thu, Aug 14, 2014 at 04:52:40PM +0800, Jason Wang wrote:
On 08/07/2014 08:47 PM, Zhangjie (HZ) wrote:
On 2014/8/5 20:14, Zhangjie (HZ) wrote:
On 2014/8/5 17:49, Michael S. Tsirkin wrote:
On Tue, Aug 05, 2014 at 02:29:28PM +0800, Zhangjie
On 08/14/2014 11:40 PM, Alexander Graf wrote:
On 14.08.14 07:13, Aneesh Kumar K.V wrote:
Alexey Kardashevskiy a...@ozlabs.ru writes:
fc95ca7284bc54953165cba76c3228bd2cdb9591 claims that there is no
functional change but this is not true as it calls get_order() (which
takes bytes) where it
Hi Ying-Shiuan Pan,
I don't know why for missing your mail in mailbox. Sorry about that.
The results of vhost-net performance have been attached in another mail.
Do you have a plan to renew your patchset to support irqfd. If not,
we will try to finish it based on yours.
On 2014/8/14 11:50, Li
After rx vq was enabled, we never stop polling its socket. This is sub optimal
when may lead unnecessary wake-ups after the rx net work has already been
queued. This could be optimized by stopping polling the rx net sock when
processing both rx and tx and restart it afterward. This could save
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 or badly-implemented hypervisor is a scenario that's
irrelevant -- such a setup is bound to
Hi Linus,
Sending directly to you with the commit log changes Ted Ts'o pointed
out. Not sure if Rusty's back after his travel, but this already has
his s-o-b.
Please pull.
The following changes since commit c9d26423e56ce1ab4d786f92aebecf859d419293:
Merge tag 'pm+acpi-3.17-rc1-2' of
On 14.08.14 07:13, Aneesh Kumar K.V wrote:
Alexey Kardashevskiy a...@ozlabs.ru 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 08/14/2014 11:40 PM, Alexander Graf wrote:
On 14.08.14 07:13, Aneesh Kumar K.V wrote:
Alexey Kardashevskiy a...@ozlabs.ru writes:
fc95ca7284bc54953165cba76c3228bd2cdb9591 claims that there is no
functional change but this is not true as it calls get_order() (which
takes bytes) where it
38 matches
Mail list logo
