Peter Maydell writes:
> On 25 July 2013 14:33, Paolo Bonzini wrote:
>> Il 25/07/2013 15:28, Peter Maydell ha scritto:
> If you want to prevent minor architecture regressions, add unit tests.
>>> Unit tests won't help with the periodic "doesn't compile on 32 bit
>>> systems" regressions, of
Peter Maydell writes:
> On 25 July 2013 14:33, Paolo Bonzini wrote:
>> Il 25/07/2013 15:28, Peter Maydell ha scritto:
> If you want to prevent minor architecture regressions, add unit tests.
>>> Unit tests won't help with the periodic "doesn't compile on 32 bit
>>> systems" regressions, of
Applied. Thanks.
Regards,
Anthony Liguori
On 25 July 2013 14:33, Paolo Bonzini wrote:
> Il 25/07/2013 15:28, Peter Maydell ha scritto:
>>> > If you want to prevent minor architecture regressions, add unit tests.
>> Unit tests won't help with the periodic "doesn't compile on 32 bit
>> systems" regressions, of course...
>
> Buildbots (and h
Il 25/07/2013 15:28, Peter Maydell ha scritto:
>> > If you want to prevent minor architecture regressions, add unit tests.
> Unit tests won't help with the periodic "doesn't compile on 32 bit
> systems" regressions, of course...
Buildbots (and having maintainers add buildbots for their trees) woul
On 25 July 2013 14:25, Anthony Liguori wrote:
> If you want to prevent minor architecture regressions, add unit tests.
Unit tests won't help with the periodic "doesn't compile on 32 bit
systems" regressions, of course...
-- PMM
Paolo Bonzini writes:
> Il 25/07/2013 12:23, Benjamin Herrenschmidt ha scritto:
>> On Thu, 2013-07-25 at 10:38 +0100, Peter Maydell wrote:
>>> On 25 July 2013 10:00, Benjamin Herrenschmidt
>>> wrote:
That's fine, I know you can fix stuff :-) I'm just really annoyed that
upstream qemu
Benjamin Herrenschmidt writes:
> On Thu, 2013-07-25 at 10:40 +0200, Paolo Bonzini wrote:
>> In any case, let me reinforce point 6 above. The patches were not
>> reverted because nobody posted the patches to do so. Until someone
>> does
>> so, it is basically Anthony's call. If he trusts people
Il 25/07/2013 12:23, Benjamin Herrenschmidt ha scritto:
> On Thu, 2013-07-25 at 10:38 +0100, Peter Maydell wrote:
>> On 25 July 2013 10:00, Benjamin Herrenschmidt
>> wrote:
>>> That's fine, I know you can fix stuff :-) I'm just really annoyed that
>>> upstream qemu remained broken for so long (an
On Thu, 2013-07-25 at 11:40 +0200, Paolo Bonzini wrote:
> > I think that for the minor architectures we just have to make
> > sure that we do yell loudly when things are broken, because
> > the nature of things is that people won't notice. Maybe we should
> > have a qemu-urgent list to parallel qem
On Thu, 2013-07-25 at 10:38 +0100, Peter Maydell wrote:
> On 25 July 2013 10:00, Benjamin Herrenschmidt
> wrote:
> > That's fine, I know you can fix stuff :-) I'm just really annoyed that
> > upstream qemu remained broken for so long (and still is) while the whole
> > thing derailed into a mostly
Il 25/07/2013 11:38, Peter Maydell ha scritto:
> On 25 July 2013 10:00, Benjamin Herrenschmidt
> wrote:
>> That's fine, I know you can fix stuff :-) I'm just really annoyed that
>> upstream qemu remained broken for so long (and still is) while the whole
>> thing derailed into a mostly pointless d
On 25 July 2013 10:00, Benjamin Herrenschmidt wrote:
> That's fine, I know you can fix stuff :-) I'm just really annoyed that
> upstream qemu remained broken for so long (and still is) while the whole
> thing derailed into a mostly pointless discussion on endianness and
> nobody (including Alexey)
On Thu, 2013-07-25 at 10:40 +0200, Paolo Bonzini wrote:
> In any case, let me reinforce point 6 above. The patches were not
> reverted because nobody posted the patches to do so. Until someone
> does
> so, it is basically Anthony's call. If he trusts people to fix the
> whole thing, he has no re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 25/07/2013 08:04, Jan Kiszka ha scritto:
> On 2013-07-25 07:47, Benjamin Herrenschmidt wrote:
>> On Thu, 2013-07-25 at 15:26 +1000, Benjamin Herrenschmidt wrote:
>>> On Mon, 2013-07-22 at 10:34 -0500, Anthony Liguori wrote:
Really nice se
Il 25/07/2013 07:47, Benjamin Herrenschmidt ha scritto:
> On Thu, 2013-07-25 at 15:26 +1000, Benjamin Herrenschmidt wrote:
>> On Mon, 2013-07-22 at 10:34 -0500, Anthony Liguori wrote:
>>>
>>> Really nice series. I'd prefer we simply got rid of the endianness
>>> flag
>>> entirely but this is a goo
On 07/25/2013 04:04 PM, Jan Kiszka wrote:
> On 2013-07-25 07:47, Benjamin Herrenschmidt wrote:
>> On Thu, 2013-07-25 at 15:26 +1000, Benjamin Herrenschmidt wrote:
>>> On Mon, 2013-07-22 at 10:34 -0500, Anthony Liguori wrote:
Really nice series. I'd prefer we simply got rid of the endiann
On 2013-07-25 07:47, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-25 at 15:26 +1000, Benjamin Herrenschmidt wrote:
>> On Mon, 2013-07-22 at 10:34 -0500, Anthony Liguori wrote:
>>>
>>> Really nice series. I'd prefer we simply got rid of the endianness
>>> flag
>>> entirely but this is a good ste
On Thu, 2013-07-25 at 15:26 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2013-07-22 at 10:34 -0500, Anthony Liguori wrote:
> >
> > Really nice series. I'd prefer we simply got rid of the endianness
> > flag
> > entirely but this is a good step.
> >
> > Reviewed-by: Anthony Liguori
>
> Are yo
On Mon, 2013-07-22 at 10:34 -0500, Anthony Liguori wrote:
>
> Really nice series. I'd prefer we simply got rid of the endianness
> flag
> entirely but this is a good step.
>
> Reviewed-by: Anthony Liguori
Are you going to merge this ?
Afaik (Alexey just told me), pretty much anything IO is br
Il 22/07/2013 22:16, Hervé Poussineau ha scritto:
>> PReP is an exception, but
>> I think it could be rewritten to use an IOMMU memory region.
>
> PReP PCI I/O area is located at 0x8000, up to 0xbf7f (in main
> memory space region), while ISA I/O area is at 0x8000, up to
> 0x8000 (
Am 22.07.2013 22:16, schrieb Hervé Poussineau:
> BTW, I've a patch to really cleanup i82378 implementation (47
> insertions, 175 deletions). Should I send it now, during 1.6 soft freeze?
Yes please, since it's a PReP-only device and relevant to the general
discussion.
Andreas
--
SUSE LINUX Prod
On 22.07.2013, at 22:16, Hervé Poussineau wrote:
> Paolo Bonzini a écrit :
>> Il 22/07/2013 17:04, Peter Maydell ha scritto:
>>> On 22 July 2013 15:36, Paolo Bonzini wrote:
Il 22/07/2013 16:32, Peter Maydell ha scritto:
> In the long term it would be good to identify which boards
>
Paolo Bonzini a écrit :
Il 22/07/2013 17:04, Peter Maydell ha scritto:
On 22 July 2013 15:36, Paolo Bonzini wrote:
Il 22/07/2013 16:32, Peter Maydell ha scritto:
In the long term it would be good to identify which boards
were using isa_mmio purely for the benefit of old_portio
(which I think
Il 22/07/2013 16:32, Peter Maydell ha scritto:
> On 22 July 2013 14:54, Paolo Bonzini wrote:
>> This series drops isa_mmio and replace it with an alias of the
>> root I/O memory region. After applying back the LITTLE_ENDIAN
>> mark for PortioLists, everything works as expected: the port memory
>>
Paolo Bonzini writes:
> This series fixes the I/O port endianness problems that came when
> port I/O was made to go through the normal dispatch path. Targets
> that used isa_mmio to invoke cpu_inl and friends now tried to do
> byte swapping once more than they previously did, causing garbage
> t
Il 22/07/2013 17:04, Peter Maydell ha scritto:
> On 22 July 2013 15:36, Paolo Bonzini wrote:
>> Il 22/07/2013 16:32, Peter Maydell ha scritto:
>>> In the long term it would be good to identify which boards
>>> were using isa_mmio purely for the benefit of old_portio
>>> (which I think is basically
On 22 July 2013 15:36, Paolo Bonzini wrote:
> Il 22/07/2013 16:32, Peter Maydell ha scritto:
>> In the long term it would be good to identify which boards
>> were using isa_mmio purely for the benefit of old_portio
>> (which I think is basically "boards where the CPU has no
>> concept of port I/O
On 22 July 2013 14:54, Paolo Bonzini wrote:
> This series drops isa_mmio and replace it with an alias of the
> root I/O memory region. After applying back the LITTLE_ENDIAN
> mark for PortioLists, everything works as expected: the port memory
> regions appear directly in the FlatView with the rig
This series fixes the I/O port endianness problems that came when
port I/O was made to go through the normal dispatch path. Targets
that used isa_mmio to invoke cpu_inl and friends now tried to do
byte swapping once more than they previously did, causing garbage
to be written.
This series drops i
30 matches
Mail list logo
