On Thu, Oct 09, 2025 at 09:29:12PM +0200, Stefano Brivio wrote: > On Thu, 9 Oct 2025 14:51:02 +1100 > David Gibson wrote: > > On Wed, Oct 08, 2025 at 12:01:18PM +0200, Stefano Brivio wrote: > > > On Wed, 8 Oct 2025 11:27:32 +1100 > > > David Gibson wrote: [snip] > > > but that wasn't the case, hence (I think) the > > > current struggle. If we go in that direction, I hope it's possible. > > > > Thinking a bit more closely, I don't think it is, for much the same > > reason it wasn't in this draft. > > > > According to the rules Jon and I thrashed out elsewhere in the thread, > > there are certain guest side addresses that must be locked to use > > our_tap_mac. We're essentially shadowing something that might exist > > on the host side, so we should use our MAC not the MAC of whatever is > > shadowed. > > > > Just pre-populating an entry won't do the trick, because it could be > > overwritten if the right events occur for the shadowed host. > > Right, sorry, I omitted another bit of context: I've been suggesting to > Jon that he'd introduce some kind of "permanent" or "administrative" > bit, and keep those entries at the beginning of the chain, exactly for > the reason you mention. Ah, right. Yes, that's a good idea. > I can imagine we'll need those at some point if we ever want to offer > explicit link-layer address mapping in the future, and they're probably > convenient the day one can change map_guest_addr and map_host_loopback > at runtime. > > We can also happily skip that for the moment, though, it's another > problem we can keep for later. Right. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson