Re: Generating host code in TCG mode
Thanks Peter > 在 2023年3月19日，上午2:52，Peter Maydell 写道： > > On Fri, 17 Mar 2023 at 21:01, 沈梦姣 wrote: >> TCG knows what registers may be clobbered by a call into >> host C code (this is set up in the tcg_target_call_clobber_regs >> regset by code in tcg_target_init()), so the register allocator >> will either avoid using those registers >> >> Look at tcg_target_reg_alloc_order in i386 host, it has these >> clobber registers though it first allocates callee saved registers. > > Yes, that's the sensible order to allocate in. > >> for values that must >> be preserved across the call, or else it will spill them to >> memory. >> >> I didn’t see these clobber registers being saved to memory >> before call/jmp Host C code in i386(x86-64) host, and copy >> these memory value back to these registers > > If they were not saved to memory, then there must not have > been a 'live' value in them in the example you were looking > at. > If TCG didn't correctly handle registers that are clobbered > by calls, then it would not work at all. Yes, but it will be helpful if someone provides some hints though I’m still reviewing the code. Thanks BR > > thanks > -- PMM
Re: Generating host code in TCG mode
On Fri, 17 Mar 2023 at 21:01, 沈梦姣 wrote: > TCG knows what registers may be clobbered by a call into > host C code (this is set up in the tcg_target_call_clobber_regs > regset by code in tcg_target_init()), so the register allocator > will either avoid using those registers > > Look at tcg_target_reg_alloc_order in i386 host, it has these > clobber registers though it first allocates callee saved registers. Yes, that's the sensible order to allocate in. > for values that must > be preserved across the call, or else it will spill them to > memory. > > I didn’t see these clobber registers being saved to memory > before call/jmp Host C code in i386(x86-64) host, and copy > these memory value back to these registers If they were not saved to memory, then there must not have been a 'live' value in them in the example you were looking at. If TCG didn't correctly handle registers that are clobbered by calls, then it would not work at all. thanks -- PMM
Re: Creating virtual routers
Greetings Richard, > Sent: Friday, March 17, 2023 at 8:43 PM > From: "Lane" > To: qemu-discuss@nongnu.org > Subject: Creating virtual routers > > HI, > > I'd like to create two virtual routers where each router gives access > to it's own virtual LAN and then add vm's to each LAN. This would all > be on my localhost. > > lan1 <---> r1 <---> r2 <---> lan2 > > Can I do this with Qemu, and if so, can someone point me in the right > direction on what I need to do? > > Richard > > my home network is based on a libvirt+qemu vm with 5 nics as pass-through and one virtual nic binded to a virtual switch for host<=>vm connection and wifi based on usb running openwrt so this is doable. Dagg
Re: IPFS?
сб, 18 мар. 2023 г., 11:25 Andrew Randrianasulu : > > > пт, 17 мар. 2023 г., 19:32 Andrew Randrianasulu : > >> I was thinking about my own (audience laughs) idea of splitting qemu >> into qemu-industrial (do industrial folks *really* need this Canon camera >> machine? ) and qemu RetroGrade (with this capitalization, please) - not >> having latest Power13 codenamed " Doomsday machine" fixes, yet running with >> this Sparc framebuffer and Ppc Screamer. >> >> But of course material reality inserted itself boldly. Where to store 0.9 >> Gb and growing .git folder? >> >> So I recall I saw something named ipfs. I wonder what people may think >> about it, any usage stories? >> > > > > Apparently it *can* be used with git, but more like static (or just > rarely-changing?) repo > > https://docs.ipfs.tech/how-to/host-git-repo/ > https://www.ctrl.blog/entry/git-p2p-compared.html yet reality might be a bit too bumpy even for more relaxed project > >
Re: IPFS?
пт, 17 мар. 2023 г., 19:32 Andrew Randrianasulu : > I was thinking about my own (audience laughs) idea of splitting qemu into > qemu-industrial (do industrial folks *really* need this Canon camera > machine? ) and qemu RetroGrade (with this capitalization, please) - not > having latest Power13 codenamed " Doomsday machine" fixes, yet running with > this Sparc framebuffer and Ppc Screamer. > > But of course material reality inserted itself boldly. Where to store 0.9 > Gb and growing .git folder? > > So I recall I saw something named ipfs. I wonder what people may think > about it, any usage stories? > Apparently it *can* be used with git, but more like static (or just rarely-changing?) repo https://docs.ipfs.tech/how-to/host-git-repo/
Re: dropping 32-bit host support
пт, 17 мар. 2023 г., 20:46 Alex Bennée :
>
> Andrew Randrianasulu writes:
>
>
> > has been
> > that of contempt ("the project needs different developer culture")
> >
> > This was probably badly worded - I mean culture of dividing all patches
> into very small pieces and running
> > full compile pipeline on each nano-change very often.
> >
> > I consider this bad idea, from cpu time/energy consumption standpoint.
>
> We don't do that. The pipeline is run on each pull request which can be
> anything from a few patches to a few hundred. And the reason is obvious
> because we are guarding against introducing regressions which prior to
> the CI system were very painful to bisect, especially if detected a long
> time after their introduction.
>
> We welcome patches to improve the situation but they require careful
> analysis of what code coverage each test has before reducing potential
> duplication of CI effort. We have already made some efforts towards this
> during the 8.0 cycle however fundamentally the reason our test matrix is
> so wide is because we are supporting a very wide range of host
> architectures, operating systems and build configurations.
>
Well, then may be really consider splitting qemu? Fast-moving, well tested
part limited to most popular host/os combinations, and more slow-moving,
experimental and, ahem, *community* part, doing different release cycle,
may be different patchflow, still relying on old-fashioned user testing?
Yes, it usually considered good idea to consolidate code in upstream, but
realistically as user of less-powered aspects of qemu (m68k Macos guest
experiments , ppc sound support under macos 9/10) I already pull more than
one maintainer's branch.
I'll try to experiment locally with ipfs, may be it behaves badly with git
objects, but hey, I like old times when users were actually able to have
some resources and pool them! I like idea of un-tamperability of ipfs
copies, so hopefully hosting source code over user's machines and fetching
it from there will lessen load on more centralized servers. I am not much
of admin, but as long I just host some heap of signed objects going in and
out my involvement in process should be manageable, I hope? I do not offer
web-based hosting because, well I am living on ~20 000 rubles/month before
you subtract bills (~6500 rubles +++), so even small hosting cost push me
over the budget, sorry. But I already pay for unlimited (for now) internet,
and my desktop machine mostly collects uptime with monitor dpms off, and if
it come to it I even think I can dedicate laptop for serving common good.
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro
>
