Let compiler do slightly better optimizations using
the non-volatile __test_bit in all cases where
the values are set using the non-volatile __set_bit and
__clear_bit.
I left test_bit in place where the mask is set using
the atomic set_bit/clear_bit, for symmetry.
This shaves about 100 bytes off
One of the reasons MMIO is slower than port IO is
because it requires a page table lookup.
For normal memory accesses, this is solved by using the TLB
cache - but MMIO entries are either not present or reserved
and so are never cached.
To fix, allow installing an ioeventfd on top of a read only
me
Even when we skip data decoding, MMIO is slightly slower
than port IO because it uses the page-tables, so the CPU
must do a pagewalk on each access.
This overhead is normally masked by using the TLB cache:
but not so for KVM MMIO, where PTEs are marked as reserved
and so are never cached.
As ioev
MMIO is slightly slower than port IO because it uses the page-tables, so
the CPU must do a pagewalk on each access.
This overhead is normally masked by using the TLB cache:
but not so for KVM MMIO, where PTEs are marked as reserved
and so are never cached.
As ioeventfd memory is never read, make
Signed-off-by: Michael S. Tsirkin
---
include/uapi/linux/kvm.h | 1 +
arch/x86/kvm/x86.c| 1 +
Documentation/virtual/kvm/api.txt | 7 +++
3 files changed, 9 insertions(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 716ad4a..4509aa3 100644
-
This seems hackish - would it be better to create this region
automatically within kvm? Suggestions are welcome.
Signed-off-by: Michael S. Tsirkin
---
hw/misc/pci-testdev.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/hw/misc/pci-testdev.c b/hw/misc/pci-testdev.c
index 9414
Make mmio a subregion of the BAR.
This will allow mapping rom within the same BAR down the road.
Signed-off-by: Michael S. Tsirkin
---
hw/misc/pci-testdev.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/hw/misc/pci-testdev.c b/hw/misc/pci-testdev.c
index 6edc1cd..941
note: this makes BAR > 4K, which requires kvm unit test
patch to support such BAR. Do we need to worry about
old kvm unit test binaries? I'm guessing not ...
Signed-off-by: Michael S. Tsirkin
---
hw/misc/pci-testdev.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/mi
This adds a test for triggering ioeventfd on pagefaults.
This was used to verify that mmio ioeventfd on pagefault is
as fast as portio.
Michael S. Tsirkin (3):
pci-testdev: separate page for each mmio test
pci-testdev: add subregion
pci-testdev: add RO pages for ioeventfd
hw/misc/pci-testd
On 2015/8/30 17:20, Michael S. Tsirkin wrote:
> This seems hackish - would it be better to create this region
> automatically within kvm? Suggestions are welcome.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> hw/misc/pci-testdev.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff
The architected timer integration with the vgic had some shortcomings in
that certain guests (one being UEFI) weren't fully supported.
In fixing this I also found that we are scheduling the hrtimer for the
virtual timer way too often, with a potential performance overhead.
This series tries to ad
We currently set the physical active state only when we *inject* a new
pending virtual interrupt, but this is actually not correct, because we
could have been preempted and run something else on the system that
resets the active state to clear. This causes us to run the VM with the
timer set to fi
The GICD_ICFGR allows the bits for the SGIs and PPIs to be read only.
We currently simulate this behavior by writing a hardcoded value to the
register for the SGIs and PPIs on every write of these bits to the
register (ignoring what the guest actually wrote), and by writing the
same value as the re
Some times it is useful for architecture implementations of KVM to know
when the VCPU thread is about to block or when it comes back from
blocking (arm/arm64 needs to know this to properly implement timers, for
example).
Therefore provide a generic architecture callback function in line with
what
Mapped interrupts on arm/arm64 is a tricky concept and the way we deal
with them is not apparently easy to understand by reading various specs.
Therefore, add a proper documentation file explaining the flow and
rationale of the behavior of the vgic.
Some of this text was contributed by Marc Zyngi
Currently vgic_process_maintenance() processes dealing with a completed
level-triggered interrupt directly, but we are soon going to reuse this
logic for level-triggered mapped interrupts with the HW bit set, so
move this logic into a separate static function.
Probably the most scary part of this
We currently schedule a soft timer every time we exit the guest if the
timer did not expire while running the guest. This is really not
necessary, because the only work we do in the timer work function is to
kick the vcpu.
Kicking the vcpu does two things:
(1) If the vpcu thread is on a waitqueue
The arch timer currently uses edge-triggered semantics in the sense that
the line is never sampled by the vgic and lowering the line from the
timer to the vgic doesn't have any affect on the pending state of
virtual interrupts in the vgic. This means that we do not support a
guest with the otherwi
We currently initialize the SGIs to be enabled in the VGIC code, but we
use the VGIC_NR_PPIS define for this purpose, instead of the the more
natural VGIC_NR_SGIS. Change this slightly confusing use of the
defines.
Note: This should have no functional change, as both names are defined
to the numb
Provide a better quality of implementation and be architecture compliant
on ARMv7 for the architected timer by resetting the CNTV_CTL to 0 on
reset of the timer, and call kvm_timer_update_state(vcpu) at the same
time, ensuring the timer output is not asserted after, for example, a
PSCI system reset
The VGIC and timer code for KVM arm/arm64 doesn't have any tracepoints
or tracepoint infrastructure defined. Rewriting some of the timer code
handling showed me how much we need this, so let's add these simple
trace points once and for all and we can easily expand with additional
trace points in t
The timer and vgic code didn't have tracepoints for quite a while and
we've been adding those ad-hoc when doing development a lot of times.
Add some simple tracepoints for those parts of KVM to get the
infrastructure in place.
Also improve the kvm_exit tracepoint on arm/arm64 to print something
me
The ARM architecture only saves the exit class to the HSR (ESR_EL2 for
arm64) on synchronous exceptions, not on asynchronous exceptions like an
IRQ. However, we only report the exception class on kvm_exit, which is
confusing because an IRQ looks like it exited at some PC with the same
reason as th
On Fri, Aug 28, 2015 at 03:56:09PM +0300, Pavel Fedin wrote:
> This patchset adds necessary userspace API in order to support vGICv3 live
> migration. This includes accessing GIC distributor and redistributor memory
> regions using device attribute ioctls, and system registers of
> CPU interface us
On Fri, Aug 28, 2015 at 03:56:10PM +0300, Pavel Fedin wrote:
> The access is done similar to GICv2, using KVM_DEV_ARM_VGIC_GRP_DIST_REGS
> and KVM_DEV_ARM_VGIC_GRP_REDIST_REGS with KVM_SET_DEVICE_ATTR and
> KVM_GET_DEVICE_ATTR ioctls.
>
> Registers are always assumed to be of their native size, 4
On Fri, Aug 28, 2015 at 03:56:12PM +0300, Pavel Fedin wrote:
> This commit adds accessors for all registers, being part of saved vGIC
> context in the form of ICH_VMCR_EL2. This is necessary for enabling vGICv3
> live migration.
>
> Signed-off-by: Pavel Fedin
> ---
> arch/arm64/kvm/sys_regs.c
On Tue, Aug 11, 2015 at 10:34:07AM +0300, Pavel Fedin wrote:
> Print exception vector name, exception class and PC translated to EL1 virtual
> address. Significantly aids debugging HYP crashes without special means like
> JTAG.
my overall concern with this patch is that it adds complexity to an
al
On 30 August 2015 at 17:50, Christoffer Dall
wrote:
> I had imagined we would encode the GICv3 register accesses through the
> device API and not through the system register API, since I'm not crazy
> about polluting the general system register handling logic with GIC
> registers solely for the pu
Hi All,
Does anyone know how to transfer data buffer through Hypercall?
According to the current implementation from "kvm_emulate_hypercall",
it only takes a primitive type as parameters through different
registers. Can we use hyprecall like read/write system call to
transfer data between guest and
On 08/30/2015 05:12 PM, Michael S. Tsirkin wrote:
Even when we skip data decoding, MMIO is slightly slower
than port IO because it uses the page-tables, so the CPU
must do a pagewalk on each access.
This overhead is normally masked by using the TLB cache:
but not so for KVM MMIO, where PTEs ar
On 08/26/2015 01:10 PM, Jason Wang wrote:
> On 08/25/2015 07:51 PM, Michael S. Tsirkin wrote:
>> > On Tue, Aug 25, 2015 at 05:05:47PM +0800, Jason Wang wrote:
>> > We register wildcard mmio eventfd on two buses, one for KVM_MMIO_BUS
>> > and another is KVM_FAST_MMIO_BUS. This leads to i
Hi Stefan,
On 08/28/2015 07:58 PM, Stefan Hajnoczi wrote:
+goto do_unmap;
+}
+
+nvdimm->device_index = new_device_index();
+sprintf(name, "NVDIMM-%d", nvdimm->device_index);
+memory_region_init_ram_ptr(&nvdimm->mr, OBJECT(dev), name, nvdimm_size,
+
On 08/28/2015 07:59 PM, Stefan Hajnoczi wrote:
On Wed, Aug 26, 2015 at 06:42:01PM +0800, Xiao Guangrong wrote:
On 08/26/2015 12:16 AM, Stefan Hajnoczi wrote:
On Fri, Aug 14, 2015 at 10:52:06PM +0800, Xiao Guangrong wrote:
+#ifdef NVDIMM_DEBUG
+#define nvdebug(fmt, ...) fprintf(stderr, "nvd
Hello!
> my overall concern with this patch is that it adds complexity to an
> already really bad situation, and potentially increases the likelihood
> of not seeing any debug info at all.
Why? In this case we currently already drop into C code. I do the same, with
some more useful
printout. W
On 08/28/2015 08:01 PM, Stefan Hajnoczi wrote:
On Wed, Aug 26, 2015 at 06:46:35PM +0800, Xiao Guangrong wrote:
On 08/26/2015 12:23 AM, Stefan Hajnoczi wrote:
On Fri, Aug 14, 2015 at 10:52:07PM +0800, Xiao Guangrong wrote:
static void dsm_write(void *opaque, hwaddr addr,
35 matches
Mail list logo
