From: David Matlack
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 so that future access
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 t
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 vfio.txt
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 s
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 ne
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 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().
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'
On Thu, Jul 10 2014 at 3:42:31 pm BST, Christoffer Dall
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 device; the
> common scenario
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
https://lists.gnu.org/archive/ht
On Thu, Aug 14, 2014 at 12:01 AM, Xiao Guangrong
wrote:
> From: David Matlack
>
> 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-enable
On Wed, Aug 13, 2014 at 10:43 PM, Andy Lutomirski 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 code, especiall
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 to
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
Cc: Laszlo Ersek
Cc: qemu-s
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 i
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
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.
>
> Signed
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
---
x86/pmu.c | 6 +++---
1 file changed, 3 insertion
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 i
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 a
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 ra
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 none
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 i
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
Reviewed-by: Laszlo Ersek
C
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 a
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/
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 +080
On 08/14/2014 11:40 PM, Alexander Graf wrote:
>
> On 14.08.14 07:13, Aneesh Kumar K.V wrote:
>> 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
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 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 unnec
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 ca
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
git://gi
36 matches
Mail list logo
