t will not
get this interrupt.
This patch fixes the problem by bringing back unconditional setting of
LR_STATE_PENDING bit.
The bug was caught on Cavium ThunderX machine, kernel v4.1.6, running
qemu "virt" guest, where it affected pl011 driver.
Signed-off-by: Pavel Fedin
---
vir
FIFO.
Could this be some
bug in kernel's pl011 driver itself, which does something wrong and does not
handle interrupts in a
proper way during output?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send t
--
Alex, are you reading us? Can you explain, why you introduced that extra check?
> And what you're suggesting is to actually introduce a bug.
Why would that be a bug, if it was not a bug in kernel 4.0?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
is
queued. Can we say
that this is wrong?
If you agree, may be do something else instead? May be we should cancel such
"ghost" interrupts
early, avoiding immediate and completely unnecessary maintenance interrupts
upon guest entry?
Kind regards,
Pavel Fedin
Expert Engineer
Samsun
an alternate solution like this,
i will test it, and
adjust if needed. My "bad codebase, broken HW and buggy userspace" appears to
be particulary prone
to finding these problems, i think it's going to be a nice testbed. :)
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electro
nning qemu "virt" guest,
where it was caused by emulated pl011.
Signed-off-by: Pavel Fedin
---
virt/kvm/arm/vgic.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 34dad3c..bf155e3 100644
--- a/virt/kvm/arm/vgic.
eans that we are going to lose everything.
An alternate would be: clear the bit, THEN call vgic_update_state() which
would set it back if
necessary. But does this extra bit of complexity worth anything, given one
paragraph above?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Researc
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 using register get/set ioctls.
Pavel Fedin (3):
KVM: arm64
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 | 176 +
include/linux/irqchip
Call accessor functions if the register is defined in the list but does
not have accociated cell in CPU context.
This allows to implement accessors for vGIC CPU interface, necessary for
live migration.
Signed-off-by: Pavel Fedin
---
arch/arm64/kvm/sys_regs.c | 47
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 or 8 bytes.
Signed-off-by: Pavel Fedin
---
arch/arm64/include/uapi
atch helped a lot to find out what was wrong. The main
missing information
was vector number, and translated PC is also useful.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
t
ed on. By the way,
handling it in userspace would also be simpler.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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
d implementing this as
device attribute would, i guess, give no difference from code's point of view.
We would have to encode system register numbers into attribute, then perform
table lookup, actually duplicating our system register access code. Does it
worth that?
Kind regards,
Pavel Fedi
ad HYP_PAGE_OFFSET
>> -.quad PAGE_OFFSET
> why can you get rid of this?
Because i was used only to translate base address of text message, which moved
to C code.
> I'll think about it.
Ok.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russ
Hello! Two weeks has passed, i have fixed up Marc's notes, so PING...
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf
> Of Pave
t difficult to deal
with CPU fd's.
Because anyway you have to iterate through all VCPUs in order to save state
correctly.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe kvm"
tate of any
other vCPUs. And, since i am getting/setting its registers, i assume that the
vCPU is not running.
Well, i added the check. What next?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe
y.
I thought about it too, it's inconvenient. In the userland you would have to
do two accesses and
merge the result. It's just tedious. After all this API is not emulating guest
behavior, it's just
for reading/writing GIC state.
So on next respin i'll add size bit.
Kind
for distributor and redistributor register
accesses, do not assume size any more.
- Lots of refactor and reusable code extraction.
- Added forgotten documentation
Pavel Fedin (5):
KVM: arm/arm64: Refactor vGIC attributes handling code
KVM: arm64: Implement vGICv3 distributor and redistribu
full 64-bit
accesses.
Signed-off-by: Pavel Fedin
---
Documentation/virtual/kvm/devices/arm-vgic.txt | 34 -
arch/arm64/include/uapi/asm/kvm.h | 2 +
virt/kvm/arm/vgic-v3-emul.c| 96 ++
3 files changed, 115 insertions(+), 17 deletions
In order to implement vGICv3 CPU interface access, we will need to perform
table lookup of system registers. We would need both index_to_params() and
find_reg() exported for that purpose, but instead we export a single function
which combines them both.
Signed-off-by: Pavel Fedin
---
arch/arm64
Replace Rt with data pointer in struct sys_reg_params. This will allow to
reuse system register handling code in implementation of vGICv3 CPU
interface access API. Additionally, got rid of "massive hack"
in kvm_handle_cp_64().
Signed-off-by: Pavel Fedin
---
arch/arm64/kvm/
Separate all implementation-independent code in vgic_attr_regs_access()
and move it to vgic.c. This will allow to reuse this code for vGICv3
implementation.
Signed-off-by: Pavel Fedin
---
virt/kvm/arm/vgic-v2-emul.c | 126 +---
virt/kvm/arm/vgic.c
running.
Signed-off-by: Pavel Fedin
---
Documentation/virtual/kvm/devices/arm-vgic.txt | 38 +++-
arch/arm64/include/uapi/asm/kvm.h | 7 +
include/linux/irqchip/arm-gic-v3.h | 18 +-
virt/kvm/arm/vgic-v3-emul.c| 246 +
4 files
d, since id is actually an index, may be we should fix up docs?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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
accesses, do not assume size any more.
- Lots of refactor and reusable code extraction.
- Added forgotten documentation
Pavel Fedin (5):
KVM: arm/arm64: Refactor vGIC attributes handling code
KVM: arm64: Implement vGICv3 distributor and redistributor access from
userspace
KVM: arm64:
CPUs.
Some registers are 64-bit wide according to the specification.
KVM_DEV_ARM_VGIC_64BIT flag is introduced, allowing to perform full 64-bit
accesses.
Signed-off-by: Pavel Fedin
---
Documentation/virtual/kvm/devices/arm-vgic.txt | 35 --
arch/arm64/include/uapi/asm/kvm.h
Replace Rt with data pointer in struct sys_reg_params. This will allow to
reuse system register handling code in implementation of vGICv3 CPU
interface access API. Additionally, got rid of "massive hack"
in kvm_handle_cp_64().
Signed-off-by: Pavel Fedin
---
arch/arm64/kvm/
running.
Signed-off-by: Pavel Fedin
---
Documentation/virtual/kvm/devices/arm-vgic.txt | 38 +++-
arch/arm64/include/uapi/asm/kvm.h | 7 +
include/linux/irqchip/arm-gic-v3.h | 18 +-
virt/kvm/arm/vgic-v3-emul.c| 244 +
4 files
In order to implement vGICv3 CPU interface access, we will need to perform
table lookup of system registers. We would need both index_to_params() and
find_reg() exported for that purpose, but instead we export a single
function which combines them both.
Signed-off-by: Pavel Fedin
---
arch/arm64
Separate all implementation-independent code in vgic_attr_regs_access()
and move it to vgic.c. This will allow to reuse this code for vGICv3
implementation.
Signed-off-by: Pavel Fedin
---
virt/kvm/arm/vgic-v2-emul.c | 126 +---
virt/kvm/arm/vgic.c
s it worth
that? In the next respin
i'd better add this explanation to commit message. Would it be OK?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to
GRP_CPU_REGS:
--- cut ---
bits: | 63 .. 56 | 55 .. 48 | 47 ... 40 | 39 .. 32 | 31 .. 0 |
values: | arch | size | reserved | cpu id | reg id |
--- cut ---
arch = KVM_REG_ARM64 and size = KVM_REG_SIZE_U64. I decided not to invent own
macro.
Kind regards,
Pavel Fedin
E
x27;params.val =
vcpu_reg(vcpu, Rt)'. So
i decided to change it to u_long * instead of having casts here and there. Do
you like casts?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "
extend "cpu id" (actually CPU index) field to 31 bit. :)
It's friday evening here, work week is almost over, i'll read your replies 2
days later on monday.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list:
function, under
dev->kvm->lock mutex, out of 'cpuid' index.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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
le64(reg);
else
*((__le32 *)&data) = cpu_to_le32(*((__le32 *)®);
isn't this even more ugly? Regardless of where it is placed.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send
Hello Andre! I haven't heard from you on any of my questions. But,
nevertheless, i would like to
inform you (and other interested people) that i'm leaving on vacation, and will
be back 2 weeks
later. Just in case if someone writes me something and i don't reply.
Kind regar
Hello Andre and others!
How are things going? I see the last message in thread something like 1 month
old, then silence...
Our project relies on this feature, any assistance needed?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from
s with the rest of that patch set? Does it need rebase or what ?
By the way, after this is applied, we can drop useless check inside
vgic_v2_map_resources().
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "
l be missing 'arch' and 'size' field, and instead i will
use
KVM_DEV_ARM_VGIC_64BIT flag for length specification, the same as for
redistributor.
Will this be OK ?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this
will also be reset if this was the only pending
interrupt, saving us from unnecessary wakeups.
The bug was caught on ARM64 kernel v4.1.6, running qemu "virt" guest,
where it was caused by emulated pl011.
Signed-off-by: Pavel Fedin
---
v1 => v2:
Recheck status and clear irq_p
ng pending_on_cpu saves from
unnecessary wakeups IIRC.
Posting v2...
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
M
refactor and reusable code extraction.
- Added forgotten documentation
Pavel Fedin (7):
KVM: arm/arm64: Move endianness conversion out of
vgic_attr_regs_access()
KVM: arm/arm64: Refactor vGIC attributes handling code
KVM: arm/arm64: Fix the documentation
KVM: arm64: Implement
endianness conversion and
masking. Masking is not used here (the mask is set to ~0), so we just move
out the remaining endianness conversion.
Signed-off-by: Pavel Fedin
---
virt/kvm/arm/vgic-v2-emul.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/virt/kvm/arm
running.
Signed-off-by: Pavel Fedin
---
Documentation/virtual/kvm/devices/arm-vgic.txt | 38 +++-
arch/arm64/include/uapi/asm/kvm.h | 7 +
include/linux/irqchip/arm-gic-v3.h | 18 +-
virt/kvm/arm/vgic-v3-emul.c| 244 +
4 files
Separate all implementation-independent code in vgic_attr_regs_access()
and move it to vgic.c. This will allow to reuse this code for vGICv3
implementation.
Signed-off-by: Pavel Fedin
---
virt/kvm/arm/vgic-v2-emul.c | 118 +---
virt/kvm/arm/vgic.c
Replace Rt with data pointer in struct sys_reg_params. This will allow to
reuse system register handling code in implementation of vGICv3 CPU
interface access API. Additionally, got rid of "massive hack"
in kvm_handle_cp_64().
Signed-off-by: Pavel Fedin
---
arch/arm64/kvm/
In order to implement vGICv3 CPU interface access, we will need to perform
table lookup of system registers. We would need both index_to_params() and
find_reg() exported for that purpose, but instead we export a single
function which combines them both.
Signed-off-by: Pavel Fedin
Reviewed-by
CPUs.
Some registers are 64-bit wide according to the specification.
KVM_DEV_ARM_VGIC_64BIT flag is introduced, allowing to perform full 64-bit
accesses. vgic_attr_regs_access() has also been fixed up in order to be
able to perform 64-bit accesses correctly.
Signed-off-by: Pavel Fedin
During refactoring we noticed some mistakes in the documentation.
Correct them.
Signed-off-by: Pavel Fedin
---
Documentation/virtual/kvm/devices/arm-vgic.txt | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/Documentation/virtual/kvm/devices/arm-vgic.txt
b
t's move on. :)
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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
Hello!
> I reworked the commit message and applied this patch.
Thank you very much.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vg
n some other guests which
just expect physical
timer to be there.
Both approaches have their own limitations, but anyway this is much better
than nothing. What do
you think, and which approach do you like more?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
_init() (which is made reentrant by checking for dist->pendbaser != NULL)
is now called from
within two places:
a) vits_map_resources()
b) handle_mmio_pendbaser_redist()
Therefore, all allocations happen either on first vCPU run, or on first
PENDBASER access, whatever
comes first. An alter
Hello!
> I like the latter. But I guess one could even do both?
You know, you are right, they absolutely do not contradict each other.
Patch set for #1 is quite not big, if you are interested, and nobody votes
strongly against, i can
rebase it to 4.3 and post.
Kind regards,
Pavel Fe
ic->nr_lr)
iteration instead. The rest
of mechanism will work as it is, there's no need to remove the state tracking
bitmap and
optimization itself.
I am currently testing this approach and preparing my alternative patch for
upstreaming.
Kind regards,
Pavel Fedin
Expert Engineer
Samsun
late the physical timer in QEMU.
Of course it is, and with TCG it works. But we currently cannot use it with
KVM because KVM assumes that it emulates all CP15 (or system) registers by
itself, and never hands any of them outside.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Rese
ogic just
works everywhere.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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
ibility.
> - What is wrong with exposing another, memory mapped timer and remove
> the architected timer entirely?
Well... qemu guys don't want to remove CP15, i already proposed it, and it was
very simple thing to
do. :) But, again, this is also device-tree-based, the same conce
> a moot optimization to me.
I'll take a look. You seem to be right, lr_used became a direct (well,
inverted) copy of elrsr
after full elrsr synchronization was introduced long time ago. It's just
current code relying on
lr_used everywhere.
Kind regards,
Pavel Fedin
Expert Eng
d and
elrsr_ptr will diverge
at this point, and this function actually brings them into sync. And it relies
on lr_used for the
loop to operate correctly (no idea why we use "for" loop here with extra check
instead of
"for_each_set_bit(lr, vgic_cpu->lr_used, vgic->nr_lr)",
this information is enough to track LR
usage.
This patchset is made against linux-next of 02.10.2015. Thanks to Andre
for pointing out some 4.3 specifics.
Pavel Fedin (2):
Optimize away redundant LR tracking
Merge vgic_set_lr() and vgic_sync_lr_elrsr()
include/kvm/arm_vgic.h | 7
elrsr/aisr
in sync with software model"), because together with lr_used we also update
elrsr. This allows to easily replace lr_used with elrsr, inverting all
conditions (because in elrsr '1' means 'free').
Signed-off-by: Pavel Fedin
---
include/kvm/arm_vgic.h | 6 ---
zero
anyway.
Signed-off-by: Pavel Fedin
---
include/kvm/arm_vgic.h | 1 -
virt/kvm/arm/vgic-v2.c | 5 -
virt/kvm/arm/vgic-v3.c | 5 -
virt/kvm/arm/vgic.c| 30 --
4 files changed, 4 insertions(+), 37 deletions(-)
diff --git a/include/kvm/arm_vgic.h b
reason expect both timers (are there any? RTOS?)
So, what is your final word? Would you consider this improvement?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a
Jump to correct label and free kvm_host_cpu_state
Signed-off-by: Pavel Fedin
---
arch/arm/kvm/arm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index dc017ad..78b2869 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
Hello! Sorry if you're terribly busy, but... small gentle PING...
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: kvmarm-boun...@lists.cs.columbia.edu
> [mailto:kvmarm-boun...@lists.cs.columbia.edu] On
>
while it's being processed.
The question is - how can we handle it? Should we have one more bitwise table
for active LPIs, or
is it enough to remember only a single, currently active LPI? Can LPIs be
preempted on a real
hardware, or not?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung E
f we map a pointer directly into guest's memory (which it writes
to
PROPBASER/PENDBASER), and just keep it? There will be no issues with caching
and synchronization at
all.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: sen
l, if we think a bit better, in case of pending bit modification, the
operations on both
guest and host side have to be atomic, otherwise we can clobber our table if,
for example, both host
and guest modify adjacent bits. And there's no way to interlock with the guest.
So, OK, i accept
your p
push active state there, just for migration. Would this be a big violation of
specification? It says
nothing about these bits at all.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe kvm" i
uot;Properties of LPI".
And another thread,
http://lists.xen.org/archives/html/xen-devel/2014-09/msg01141.html, says that
virtual LPIs actually do have active state in LR.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: s
electrons.com/source/include/linux/kvm_host.h#L427
I decided to change this after
http://www.spinics.net/lists/kvm-arm/msg16359.html, Andre clearly
mistook this ID for being affinity value.
Before GICv3 nobody saw the difference because we had only up to 16 CPUs, with
IDs from 0 to 15,
ex,
which it uses for GICv2 accesses.
Keeping index allows to reuse more code, and provides better backwards
compatibility. So could we
do this?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe
s do not have an active state, and transition to the inactive state on being
acknowledged by a PE
--- cut ---
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to m
lue, and if you
say "that doesn't
count, we don't have to be compatible with GICv2", i'll accept this and proceed
with the rewrite.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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
should also work fine
with v3, replacing
patches 0001 and 0002. Merging this at the moment.
Yes, vgic_unqueue_lpi() falls out of use, but this is temporary, because it
will be very useful for
live migration.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
es (/me looks at André... ;-)
It a little bit clashes, patch No 0012 needs small modifications, but i'd say
they are trivial. If
you want, i could rebase the whole thing on top of current kvmarm.git by myself.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Rus
me pieces
are missing, considering my live migration W.I.P (see patch below). Together
with this, vITS v3
backported to v4.2.2 and...
Tested-by: Pavel Fedin
---
>From b08e9ba1da69f9cf5731c89a4ff39561cd16e6ea Mon Sep 17 00:00:00 2001
From: Pavel Fedin
Date: Thu, 8 Oct 2015 14:43:23 +0300
Sub
beat one, i
go your way. :) Don't know if i'll be able to roll out v5 tomorrow, but i think
on monday i'll
definitely do.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe
somewhere?
I rolled it out a week ago:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg325331.html. I
tried to get reviewed/accepted/whatever at least data structure part, but Peter
replied that he
isn't interested before we have the kernel.
Kind regards,
Pavel Fedin
Expert E
ication: do you really want it to be different from
KVM_DEV_ARM_VGIC_GRP_CPU_REGS?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.o
The question was just a
clarification. Ok, this is
not a problem. By the way, i've just finished v5 patchset, now need to rewrite
qemu and test before
posting it.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the
needed.
--- cut ---
Would you be happy with this? An alternative would be to add a check for
pending LPIs, but wouldn't
it just be too complex for a simple problem?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: se
ay is to introduce a function which would check for any
pending LPIs. I will
suggest a fix on top of the current series after some time.
I'm cc'ing this whole discussion to Andre.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe
Hello!
> >
> ok, fair enough. This kind of rationale is helpful to put in the commit
> text though.
By the way, may be apply this as a standalone patch? Should i post a
standalone version with the
updated commit message then?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung
} else {
> + BUG_ON(!(vlr.state & LR_STATE_MASK));
> +
> + /* Reestablish SGI source for pending and active SGIs */
> + if (vlr.irq < VGIC_NR_SGIS)
> + add_sgi_source(vcpu, vlr.irq, vlr.source);
> +
> + if (vlr.state & LR_STATE_PENDING)
> + vgic_dist_irq_set_pending(vcpu, vlr.irq);
> +
> + if (vlr.state & LR_STATE_ACTIVE) {
> + if (vlr.state & LR_STATE_PENDING) {
> + vgic_irq_set_active(vcpu, vlr.irq);
> + } else {
> + /* Active-only IRQs stay in the LR */
> + pending = true;
> + continue;
> + }
> }
> }
>
> @@ -1512,6 +1548,7 @@ static void __kvm_vgic_sync_hwstate(struct kvm_vcpu
> *vcpu)
> }
> vgic_update_state(vcpu->kvm);
>
> + /* vgic_update_state would not cover only-active IRQs or LPIs */
> if (pending)
> set_bit(vcpu->vcpu_id, dist->irq_pending_on_cpu);
> spin_unlock(&dist->lock);
> --
> 2.5.1
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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
es.
- Introduce size specifier for distributor and redistributor register
accesses, do not assume size any more.
- Lots of refactor and reusable code extraction.
- Added forgotten documentation
Christoffer Dall (1):
KVM: arm/arm64: Update API documentation
Pavel Fedin (6):
KVM: arm/arm64: Mo
ould cause rollover. For write operations
this would overwrite lower word with the upper one (which would normally
be 0), for read operations this would cause duplication of the same word
in both halves.
Signed-off-by: Pavel Fedin
---
arch/arm64/include/uapi/asm/kvm.h | 3 +-
include/linux/irq
Replace Rt with data pointer in struct sys_reg_params. This will allow to
reuse system register handling code in implementation of vGICv3 CPU
interface access API. Additionally, got rid of "massive hack"
in kvm_handle_cp_64().
Signed-off-by: Pavel Fedin
---
arch/arm64/kvm/
Access size is always 64 bits. Since CPU interface state actually affects
only a single vCPU, no vGIC locking is done in order to avoid code
duplication. Just made sure that the vCPU is not running.
Signed-off-by: Pavel Fedin
---
arch/arm64/include/uapi/asm/kvm.h | 14 ++-
include/linux
differently.
Also, vcpu pointer has backpointer to kvm, so 'dev' was replaced with 'vcpu'.
Signed-off-by: Pavel Fedin
---
virt/kvm/arm/vgic-v2-emul.c | 120 +++-
virt/kvm/arm/vgic.c | 57 +
virt/kvm/arm/vgic.h
endianess conversion and masking.
Masking is not used here (the mask is set to ~0), so we just move out the
remaining endianess conversion.
Signed-off-by: Pavel Fedin
---
virt/kvm/arm/vgic-v2-emul.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/virt/kvm/arm
In order to implement vGICv3 CPU interface access, we will need to perform
table lookup of system registers. We would need both index_to_params() and
find_reg() exported for that purpose, but instead we export a single
function which combines them both.
Signed-off-by: Pavel Fedin
Reviewed-by
refactoring:
1. GICv2 always identified vCPU by index (using kvm_get_vcpu() function),
but "cpu id" can be mistaken for affinity ID.
2. Some error codes were wrong.
Signed-off-by: Christoffer Dall
Signed-off-by: Pavel Fedin
---
Documentation/virtual/kvm/devices/arm-vgic-v3
the interrupts.
P.S. I still sometimes lose LPIs, and this is not related to spurious
injection fix, because i
tried to omit resetting irq_pending_on_cpu bit, and still lost some LPIs. Will
try to compare with
v2, because with v2 i don't remember this problem.
Kind regards,
Pavel Fedin
Expert
knows
that with GICv2m it
should use hardcoded linear MSI->SPI mapping.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More ma
Correct some old mistakes in the API documentation:
1. VCPU is identified by index (using kvm_get_vcpu() function), but
"cpu id" can be mistaken for affinity ID.
2. Some error codes are wrong.
Signed-off-by: Pavel Fedin
---
This is a small extraction from my vGICv3 live migrat
1 - 100 of 304 matches
Mail list logo
