On 30 January 2015 at 11:48, Laszlo Ersek wrote:
> On 01/30/15 12:40, Peter Maydell wrote:
>> Just as a sanity check, do we actually have an old kernel that
>> enumerates in the opposite order (as opposed to my two-year-old
>> "I'm sure this used to be right" memories...) ?
>
> I never saw one. :)
On 01/30/15 12:40, Peter Maydell wrote:
> On 30 January 2015 at 11:38, Laszlo Ersek wrote:
>> Please note that (as far as I understand) the patch that I referenced is
>> indeed very new, it's not part of v3.18, but the reversal can easily be
>> seen with v3.18. In other words, the kernel patch I r
On 30 January 2015 at 11:39, Laszlo Ersek wrote:
> On 01/30/15 11:54, Peter Maydell wrote:
>> On 30 January 2015 at 10:48, Daniel P. Berrange wrote:
>>> Long term though it will be much better of AArch64 would just do PCI
>>> instead of MMIO bus. Then we have proper device addressing which we
>>>
On 30 January 2015 at 11:38, Laszlo Ersek wrote:
> Please note that (as far as I understand) the patch that I referenced is
> indeed very new, it's not part of v3.18, but the reversal can easily be
> seen with v3.18. In other words, the kernel patch I referenced
> introduces no functional change,
On 01/30/15 11:54, Peter Maydell wrote:
> On 30 January 2015 at 10:48, Daniel P. Berrange wrote:
>> Long term though it will be much better of AArch64 would just do PCI
>> instead of MMIO bus. Then we have proper device addressing which we
>> can control in a predictable manner that will be stable
On 01/30/15 11:48, Daniel P. Berrange wrote:
> On Fri, Jan 30, 2015 at 10:29:46AM +, Peter Maydell wrote:
>> On 30 January 2015 at 09:54, Daniel P. Berrange wrote:
>>> While it is clear there is no solution that works correctly with all
>>> kernels, I hate to think that we're going to stick wi
On 30 January 2015 at 10:54, Peter Maydell wrote:
> On 30 January 2015 at 10:48, Daniel P. Berrange wrote:
>> Long term though it will be much better of AArch64 would just do PCI
>> instead of MMIO bus. Then we have proper device addressing which we
>> can control in a predictable manner that wil
On 30 January 2015 at 10:48, Daniel P. Berrange wrote:
> Long term though it will be much better of AArch64 would just do PCI
> instead of MMIO bus. Then we have proper device addressing which we
> can control in a predictable manner that will be stable across hotplug
> and unplug and migration.
On Fri, Jan 30, 2015 at 10:29:46AM +, Peter Maydell wrote:
> On 30 January 2015 at 09:54, Daniel P. Berrange wrote:
> > While it is clear there is no solution that works correctly with all
> > kernels, I hate to think that we're going to stick with an ordering
> > that is clearly wrong for mod
On 30 January 2015 at 09:54, Daniel P. Berrange wrote:
> While it is clear there is no solution that works correctly with all
> kernels, I hate to think that we're going to stick with an ordering
> that is clearly wrong for modern kernels, forever going forward. The
> aarch64 world is only just st
On 01/30/15 10:54, Daniel P. Berrange wrote:
> On Thu, Jan 29, 2015 at 08:05:50PM +, Peter Maydell wrote:
>> On 29 January 2015 at 19:47, Laszlo Ersek wrote:
>>> On 01/29/15 20:12, Laszlo Ersek wrote:
If the guest kernel changed its "assignment strategy" at some point, but
earlier it
On Thu, Jan 29, 2015 at 08:05:50PM +, Peter Maydell wrote:
> On 29 January 2015 at 19:47, Laszlo Ersek wrote:
> > On 01/29/15 20:12, Laszlo Ersek wrote:
> >> If the guest kernel changed its "assignment strategy" at some point, but
> >> earlier it used to match the comment (and the code), then
On 29 January 2015 at 19:47, Laszlo Ersek wrote:
> On 01/29/15 20:12, Laszlo Ersek wrote:
>> If the guest kernel changed its "assignment strategy" at some point, but
>> earlier it used to match the comment (and the code), then whichever way
>> we shape the comment will be wrong for the other kerne
On 01/29/15 20:12, Laszlo Ersek wrote:
> On 01/29/15 20:01, Peter Maydell wrote:
>> On 29 January 2015 at 18:29, Laszlo Ersek wrote:
>>> Yes. The DTB is 100% fine. However, we're talking two independent
>>> mappings here. The lower level mapping is the DTB, and that's completely
>>> fine. It's han
On 01/29/15 20:09, Richard W.M. Jones wrote:
> On Thu, Jan 29, 2015 at 07:29:09PM +0100, Laszlo Ersek wrote:
>> On 01/29/15 19:15, Peter Maydell wrote:
>>> On 29 January 2015 at 17:25, Laszlo Ersek wrote:
I find that virtio-mmio devices are assigned highest-to-lowest addresses
as they ar
On 29 January 2015 at 19:09, Richard W.M. Jones wrote:
> On Thu, Jan 29, 2015 at 07:29:09PM +0100, Laszlo Ersek wrote:
>> On 01/29/15 19:15, Peter Maydell wrote:
>> > Note that you can't rely on device ordering anyway. Guests
>> > should be using UUIDs or similar to ensure they mount the
>> > righ
On 01/29/15 20:01, Peter Maydell wrote:
> On 29 January 2015 at 18:29, Laszlo Ersek wrote:
>> Yes. The DTB is 100% fine. However, we're talking two independent
>> mappings here. The lower level mapping is the DTB, and that's completely
>> fine. It's handled by the second loop in create_virtio_devi
On Thu, Jan 29, 2015 at 07:29:09PM +0100, Laszlo Ersek wrote:
> On 01/29/15 19:15, Peter Maydell wrote:
> > On 29 January 2015 at 17:25, Laszlo Ersek wrote:
> >> I find that virtio-mmio devices are assigned highest-to-lowest addresses
> >> as they are found on the command line. IOW, this code (fro
On 29 January 2015 at 18:29, Laszlo Ersek wrote:
> Yes. The DTB is 100% fine. However, we're talking two independent
> mappings here. The lower level mapping is the DTB, and that's completely
> fine. It's handled by the second loop in create_virtio_devices(). But,
> that mapping in the DTB doesn't
On 01/29/15 19:15, Peter Maydell wrote:
> On 29 January 2015 at 17:25, Laszlo Ersek wrote:
>> I find that virtio-mmio devices are assigned highest-to-lowest addresses
>> as they are found on the command line. IOW, this code (from commit
>> f5fdcd6e):
>>
>> /* Note that we have to create the tr
On 29 January 2015 at 17:25, Laszlo Ersek wrote:
> I find that virtio-mmio devices are assigned highest-to-lowest addresses
> as they are found on the command line. IOW, this code (from commit
> f5fdcd6e):
>
> /* Note that we have to create the transports in forwards order
> * so that com
On 29/01/2015 18:25, Laszlo Ersek wrote:
> Another possibility would be to replace QLIST_INSERT_HEAD() with
> QTAILQ_INSERT_TAIL() in qbus_realize(), but compared to the virt board
> code, that could very easily regress stuff.
Yes, this would be an ABI change.
Paolo
Hi,
I find that virtio-mmio devices are assigned highest-to-lowest addresses
as they are found on the command line. IOW, this code (from commit
f5fdcd6e):
/* Note that we have to create the transports in forwards order
* so that command line devices are inserted lowest address first,
23 matches
Mail list logo
