Lgtm

MIPS has been removed from the tree

Added a comment indicating that PIE is incompatible with -mno-abicalls. Thanks, @emaste.

@alfredo/ @fernando.valle_eldorado.org.br Are you planning to commit this soon?

LGTM

Grammar correction suggestions in code comments.

Minor grammar suggestions but otherwise looks good to me. Thanks!

'if _BYTE_ORDER' removed, making the code more generic, as suggested in the comments of this revision. Comments were also added explaining why endian conversion is necessary.

In D25416#569712, @fernando.valle_eldorado.org.br wrote:

@arichardson Which freebsd .img revision are you using?

In D25416#569712, @fernando.valle_eldorado.org.br wrote:

@arichardson Which freebsd .img revision are you using?

@arichardson Which freebsd .img revision are you using?

I can confirm that this makes virtio-rng work again for MIPS64. LGTM if you apply @alfredo's suggestions.

In this way the specificity of the mips is removed, the adjustments of the bus_space in the vtpci_* defines makes the code more generic.

I stepped through MIPS init in QEMU and it turns out MALTA ends up with

p sc->vtpci_res->r_bustag
$7 = (bus_space_tag_t) 0xffffffff809aefc0 <gt_pci_space>

More respose to markj feedback

Note that for instance x86 has similar issue, because hardware is free to speculatively walk page tables and load any valid PTE or intermediate paging structure. There all page table entries clearing functions take the free list pointer, where the freed page table is put. Only after the caller did IPI to invalidate TLB for cleared PTE, the pages from the list can be freed.

This looks reasonable to me aside from the style nits.

Revised version as per markj's feedback

Now without D24523 included

I believe it is better to split the review into two. The pmap_emulate_modified() looks good to me, and I do not see why the other part should block this one.

Remove mips 32bit atomic_load/store_64.

In D13586#284245, @jhb wrote:

Yes, let's kill these and fix DDB instead.

Yes, let's kill these and fix DDB instead.

In D13586#284229, @jhb wrote:

BTW, I looked and the only place atomic_load_64 and atomic_store_64 are used in sys/mips is for DDB (db_read_bytes and db_write_bytes in sys/mips/mips/db_interface.c). It is not clear to me that this actually needs to be near this fancy. Most architectures just do a simple byte loop. Only 32-bit arm, mips, and powerpc attempt to handle accesses for exact word-size specially. arm doesn't try to handle 64-bit accesses with this kind of magic. powerpc just uses a 'uint64_t' load and store via C the same as it does for other word sizes. I suspect the db_read/write_bytes can just be simplified to match what powerpc does and and use simple C load/store and then these functions can be removed.

BTW, I looked and the only place atomic_load_64 and atomic_store_64 are used in sys/mips is for DDB (db_read_bytes and db_write_bytes in sys/mips/mips/db_interface.c). It is not clear to me that this actually needs to be near this fancy. Most architectures just do a simple byte loop. Only 32-bit arm, mips, and powerpc attempt to handle accesses for exact word-size specially. arm doesn't try to handle 64-bit accesses with this kind of magic. powerpc just uses a 'uint64_t' load and store via C the same as it does for other word sizes. I suspect the db_read/write_bytes can just be simplified to match what powerpc does and and use simple C load/store and then these functions can be removed.

looks good and useful. thanks!

thanks

Cleanup on error path during attach.

I just can say that I saw some problem in that area configuring MMC device for X1000 processor a month ago and was thinking about similar change.

• Remove unused parameters in jzsmb_reset_locked
• Replace timeval usage with timespec