On 10/7/2015 2:05 PM, Peter Maydell wrote:
> On 7 October 2015 at 17:40, Mario Smarduch wrote:
>> On 10/7/2015 12:07 AM, Peter Maydell wrote:
>>> On 7 October 2015 at 01:32, Mario Smarduch wrote:
Hi Peter,
I noticed that icedcc, and 8250 don't work
with DEBUG_LL early debug pr
On Thu, Oct 08, 2015 at 06:22:34PM +0100, Suzuki K. Poulose wrote:
> On 08/10/15 15:45, Christoffer Dall wrote:
> >On Wed, Oct 07, 2015 at 10:26:14AM +0100, Marc Zyngier wrote:
> >>I just had a chat with Catalin, who did shed some light on this.
> >>It all has to do with rounding up. What you would
On 08/10/15 15:45, Christoffer Dall wrote:
On Wed, Oct 07, 2015 at 10:26:14AM +0100, Marc Zyngier wrote:
On 07/10/15 09:26, Christoffer Dall wrote:
Hi Suzuki,
I just had a chat with Catalin, who did shed some light on this.
It all has to do with rounding up. What you would like to have her
On Tue, Sep 15, 2015 at 04:41:19PM +0100, Suzuki K. Poulose wrote:
> From: "Suzuki K. Poulose"
>
> {V}TCR_EL2_TG0 is a 2bit wide field, where:
>
> 00 - 4K
> 01 - 64K
> 10 - 16K
>
> But we use only 1 bit, which has worked well so far since
> we never cared about 16K. Fix it for 16K support.
>
On Wed, Oct 07, 2015 at 10:26:14AM +0100, Marc Zyngier wrote:
> On 07/10/15 09:26, Christoffer Dall wrote:
> > Hi Suzuki,
> >
> > On Tue, Sep 15, 2015 at 04:41:12PM +0100, Suzuki K. Poulose wrote:
> >> From: "Suzuki K. Poulose"
> >>
> >> Introduce helpers for finding the number of page table
> >>
On Thu, Oct 08, 2015 at 01:36:09PM +0100, Marc Zyngier wrote:
> If a mapped interrupt is disabled, we must make sure the
> corresponding physical interrupt cannot fire, as we are not
> injecting the interrupt, and not setting the active bit.
>
> For example, a guest disabling its timer interrupt a
On 8 October 2015 at 13:45, Pavel Fedin wrote:
>> Speaking of which, does the QEMU side of this patch set require first
>> adding the GICv3 emulation for the data structures or is there a
>> stand-alone migration patch set somewhere?
>
> I rolled it out a week ago:
> https://www.mail-archive.co
On 08/10/15 13:45, Pavel Fedin wrote:
> Hello!
>
>> There's no rush, I don't think this will make it into v4.4 anyhow
>
> Did you mean 4.3 here?
No, that'd be really 4.4. 4.3 has closed 4 weeks ago, and 4.4 is about
to open. This work is unlikely to make it before 4.5 TBH.
Thanks,
M.
Hello!
> There's no rush, I don't think this will make it into v4.4 anyhow
Did you mean 4.3 here?
> Speaking of which, does the QEMU side of this patch set require first
> adding the GICv3 emulation for the data structures or is there a
> stand-alone migration patch set somewhere?
I rolled i
If a mapped interrupt is disabled, we must make sure the
corresponding physical interrupt cannot fire, as we are not
injecting the interrupt, and not setting the active bit.
For example, a guest disabling its timer interrupt at the GIC level
but leaving the timer firing would stop making progress
On Thu, Oct 08, 2015 at 03:28:40PM +0300, Pavel Fedin wrote:
> Hello!
>
> > Well, compatibility with GICv2 is the biggest mistake we made when
> > designing the GICv3 architecture. And that's why our emulation doesn't
> > give a damn about v2 compatibility.
>
> Ok, i see your arguments, and aft
On Thu, Oct 08, 2015 at 12:15:06PM +0100, Andre Przywara wrote:
> Hi,
>
> On 08/10/15 11:56, Marc Zyngier wrote:
> > On 08/10/15 11:14, Christoffer Dall wrote:
> >> Hi Pavel,
> >>
> >> On Fri, Oct 02, 2015 at 05:44:27PM +0300, Pavel Fedin wrote:
> >>> Current KVM code has lots of old redundancies,
Hello!
> Well, compatibility with GICv2 is the biggest mistake we made when
> designing the GICv3 architecture. And that's why our emulation doesn't
> give a damn about v2 compatibility.
Ok, i see your arguments, and after that it becomes a matter of personal
taste. Three beat one, i
go your w
Hello!
> Yes, I am looking at merging this. From the discussion with Pavel I
> remember some things that I disagreed with, so I may propose a follow-up
> patch. I will give this a try tomorrow.
I reply to this thread, because this relates to the whole changeset. After the
merge, some pieces
ar
Hello!
> I don't mind the simplification (Andre was already removing the
> piggybacking stuff as part of his ITS series). I'm a bit more cautious
> about the sync_elrsr stuff, but that's mostly because I've only read the
> patch in a superficial way.
If you are really afraid of it, you can omit
Hi,
On 08/10/15 11:56, Marc Zyngier wrote:
> On 08/10/15 11:14, Christoffer Dall wrote:
>> Hi Pavel,
>>
>> On Fri, Oct 02, 2015 at 05:44:27PM +0300, Pavel Fedin wrote:
>>> Current KVM code has lots of old redundancies, which can be cleaned up.
>>> This patchset is actually a better alternative to
On 08/10/15 11:14, Christoffer Dall wrote:
> Hi Pavel,
>
> On Fri, Oct 02, 2015 at 05:44:27PM +0300, Pavel Fedin wrote:
>> Current KVM code has lots of old redundancies, which can be cleaned up.
>> This patchset is actually a better alternative to
>> http://www.spinics.net/lists/arm-kernel/msg4307
Hello!
> I am a bit worries about how/if this is going to conflict with the ITS
> series and other patches in flight touchignt he vgic.
Just to note: of course i test them together. This works fine at least with
vITS v2, where it
replaces patch 0001 from the original series. I guess it should
On 8 October 2015 at 10:10, Pavel Fedin wrote:
> Sorry, didn't want to offend anyone. I just wanted to tell that i know
> that you, as maintainers, have much more power than i do, and you can
> always say "it's political decision, we just want it and that's final",
> and if you choose to do this,
Hi Pavel,
On Fri, Oct 02, 2015 at 05:44:27PM +0300, Pavel Fedin wrote:
> Current KVM code has lots of old redundancies, which can be cleaned up.
> This patchset is actually a better alternative to
> http://www.spinics.net/lists/arm-kernel/msg430726.html, which allows to
> keep piggy-backed LRs. Th
On 08/10/15 10:28, Christoffer Dall wrote:
> On Thu, Oct 08, 2015 at 12:10:35PM +0300, Pavel Fedin wrote:
>> Hello!
>>
> [...]
>>
>>> The architecture defines how to address a specific CPU, and that's using
>>> the MPIDR, not inventing our own scheme, so that's what we should do.
>>
>> But doesn'
On Thu, Oct 08, 2015 at 12:10:35PM +0300, Pavel Fedin wrote:
> Hello!
>
[...]
>
> > The architecture defines how to address a specific CPU, and that's using
> > the MPIDR, not inventing our own scheme, so that's what we should do.
>
> But doesn't the same apply to GICv2 then? It just happened
Hello!
> > One concern about this... Does it already have "We are Bosses, we Decided
> > it, It's not
> subject to
> > change, We do not care" status?
>
> That's a rather negative question.
Sorry, didn't want to offend anyone. I just wanted to tell that i know that
you, as maintainers,
have
On Tue, Oct 06, 2015 at 11:14:35AM +0300, Pavel Fedin wrote:
> 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 dc0
Hello!
Sorry for taking up your time, and thank you very much for the explanation.
> I'd appreciate if you could try to read and understand the architecture
> spec instead of randomly googling and quoting various bits of
> irrelevant information.
I give my apologizes for not having time to re
On Thu, Oct 08, 2015 at 09:52:02AM +0300, Pavel Fedin wrote:
> Hello!
>
> > > --- a/Documentation/virtual/kvm/devices/arm-vgic.txt
> > > +++ b/Documentation/virtual/kvm/devices/arm-vgic.txt
> > > @@ -44,28 +44,29 @@ Groups:
> > >Attributes:
> > > The attr field of kvm_device_attr encodes
On Thu, Oct 08, 2015 at 10:17:09AM +0300, Pavel Fedin wrote:
> Hello!
>
> > +The mpidr encoding is based on the affinity information in the
> > +architecture defined MPIDR, and the field is encoded as follows:
> > + | 63 56 | 55 48 | 47 40 | 39 32 |
> > + |
Hello!
> +The mpidr encoding is based on the affinity information in the
> +architecture defined MPIDR, and the field is encoded as follows:
> + | 63 56 | 55 48 | 47 40 | 39 32 |
> + |Aff3|Aff2|Aff1|Aff0|
One concern about th
28 matches
Mail list logo
