Back to Home / #xen / 2022 / 02 / Prev Day | Next Day
#xen IRC Logs for 2022-02-16

---Logopened Wed Feb 16 00:00:15 2022
00:03-!-jgross_ is now known as jgross
03:53<royger>no, a system wide relaxed setting would be a bad idea IMO. That's a workaround that shouldn't be used once guests have been fixed to deal with #GP as a result of accessing certain MSRs
03:53<royger>ccw: do you know which MSR is causing the #GP?
09:32-!-szy_mat [] has joined #xen
09:32-!-szy_mat is "szy_mat" on #xen
09:33<szy_mat>I'd like to thank you guys and especially some guy which gave me advice how to port Xen to new archs circa 2018/early 2019, it was just like "create arch/xxxxx folder and write asm code in place of placeholders until it will really compile"
09:33<szy_mat>yeah, it is so neat and simple
09:34<szy_mat>so my ports of Xen for m68k (intended for high-end ones) and ppc (yeah, back) are almost ready
09:35<andyhhp>wow - that's unexpected. but very welcome
09:35<szy_mat>andyhhp: was it you? your nickname sound familiar
09:36<szy_mat>and though I truly hate x86(-64), do you know can I use PAE to run PVs on a 32-bit system with like 16GB of RAM, like 3 domUs 4GB each?
09:38<szy_mat>probably some of you would need to recall that i386 Xen used segmentation limits for PV memory protection :D
09:38<andyhhp>quite possibly was me. I have vague recoolections
09:38<szy_mat>and BTW, what's XDDS and where is it happening?
09:38<szy_mat>andyhhp: so do I :)
09:39<andyhhp>Xen made a lot of use of the x86 architecture back in the day
09:39<andyhhp>even as the bits we were using were slowly becoming obsolete
09:40<andyhhp>XDDS => Xen Developer Summit? probably ought to defer that one to gwd
09:48<jgross>I think the topic of the #xen channel is a little bit outdated, it was probably set last year in summer. :-)
09:49<andyhhp>that's the reference
09:51<szy_mat>jgross: hi, out of my curiosity, you guys were able to organize XDDS at some real place on this planet last summer?
09:51<andyhhp>yeah, who does have op?
09:51<andyhhp>so it was fully virtual last year
09:51<jgross>szy_mat: no, it was a virtual event.
09:51<andyhhp>this year is looking possible for a partial in-persion, partial virtual event
09:52<szy_mat>jgross: shit, although that's what I unfortunately thought
09:52<szy_mat>andyhhp: more like Europe, North America, Asia/Pacific?
09:52<andyhhp>well we always used to cycle through those 3 GEOs on consecutive years
09:54<jgross>I think Europe would be the next physical one, as the plans for 2019 where for Europe, right?
09:54<andyhhp>yeah, the Europe physical plans have been delayed each year
09:54<szy_mat>then maybe I'd be able to host you, but send me a private message for that
09:55<szy_mat>for more details
09:55<andyhhp>so but there's been no formal annoucement yet, so still TBC
10:03<gwd>We're definitely goign to have a "hybrid" summit in Bucharest, unless something really bizarre happens
10:03<gwd>But not at that date. We're still trying to sort out a date.
10:03<szy_mat>gwd sounds nice
10:04<gwd>Where are you based?
10:04<szy_mat>western/central europe currently
10:05<szy_mat>can reach bucharest in like 2h of plane flight, or about 6-8h train or car ride
10:11<andyhhp>szy_mat: OOI, which ppc is that?
10:12<andyhhp>there are definitely some folks interested if it's Power9/10
10:12<andyhhp>some other folks*
10:12<szy_mat>yeah, the 64-bit ppc/power port would probably be ready
10:12<szy_mat>right now only dom0 I've ported is Linux
10:13<szy_mat>but well, if I could talk with some *BSD devs (and other kernels, as well)
10:13<szy_mat>gonna take my PowerBooks then :) (one is 68060-custom-upgraded and the second is PPC G4, also a big part of a custom build)
10:15<szy_mat>both are (unfortunately) 32-bit machines which I'm focused on, but the 64-bit port is somewhere in my scratchpad forlder
10:15<szy_mat>and it compiles and works in qemu
10:15<szy_mat>when talking about ppc/power, of course
10:16<szy_mat>andyhhp: POWERs have some HWM-enabling features but I don't have it yet, so it's PV-only, though it's a very nice platform for PV, unlike amd64
10:17<jgross>Are you doing the ports as a "fun project"?
10:17<szy_mat>no need for dynamic recompilation nor trap-and-emulate
10:17<szy_mat>jgross: not really
10:17<andyhhp>so @olivier set up a meeting with IBM a little while back
10:17<szy_mat>jgross: they're a part of something much bigger due Q4 2023
10:18<jgross>Oh, exciting. :-)
10:18<andyhhp>also, QubesOS are specificially interested ppc64 support too, IIRC
10:18<andyhhp>fancy writing this up and sending an email to xen-devel@ ?
10:19<szy_mat>andyhhp: sorry for that, we're probably gonna outrule QubesOS with ur release, but they're (and their contributors) up our inspirations/credits list
10:19<andyhhp>I didn't mean to imply that you ought to do the work to support Qubes. More I meant that maybe they could find some resource to help out too
10:20<szy_mat>andyhhp: when the ports will be distribution-suitable, even as alpha/bleeding-edge software, I'll surely put them on xen-devel
10:21<szy_mat>right now they work on my heavily-modified G4 and my bizzare 68060@133MHz machine and nothing more, so not yet I think
10:21<andyhhp>so we discussed stuff like this with the Risc-V port
10:21<andyhhp>right now, we've got a head.S and just enough build system to make a binary
10:21<andyhhp>and thats entirely fine to start with
10:22<szy_mat>mostly because they rely on my custom-written hwinit firmware which WILL be open-sourced (yeah, got all the Apple/other prioprietary code the f... out the PowerBook G4)
10:22<andyhhp>always the way
10:23<szy_mat>andyhhp: not to mention my custom-build 68k machine where even the GPU/actually framebuffer RAMDAC with double-buffering and some 2D acceleration is completely custom
10:23<szy_mat>andyhhp: serial ports are also custom, so you'll get absolutely no debug output
10:26<szy_mat>andyhhp: unfortunately the PPC G4 could be Meltdown/Spectre vulnerable (but no l1tf and so on...)
10:26<szy_mat>and that's another issue to think and work on
10:27<andyhhp>yeah, that topic came up specifically
10:27<szy_mat>andyhhp: the m68k machine runs AROS as domU just fine
10:27<andyhhp>we'd have to be careful about declaring security support
10:27<szy_mat>so can do the PPC one, but it doesn't yet
10:28<szy_mat>68060 isn't vulnerable to any of those HW-wise
10:28<szy_mat>I mean, 68060 particularly is unusually CISC with almost no microcode, so you can see everything on high-resolution die scans
10:29<szy_mat>it doesn't apply to older members of the family
10:29<Plam>hello szy_mat this is an interesting topic (I'm Olivier, I organized a call between IBM/OpenPOWER and some Xen devs in November)
10:30<szy_mat>hi Plam, what was the outcome?
10:30<andyhhp>Plam: it wasn't last November, any more... ;)
10:30<Plam>well: hardware is hard to get, mainly
10:30<Plam>ah yeah, November 2020, frack.
10:30<szy_mat>TALOS II is the only one off-the-shelf dev available, but it's pricey
10:31<Plam>that was somehow the conclusion
10:31<Plam>we could have a small discount on it
10:31<szy_mat>that's why I'm developing on an 32-bit PowerBook
10:31<Plam>but that was pretty much it
10:31<szy_mat>Plam: okay, still nice
10:31<Plam>however, if there's active dev, we can participate to get better hardware
10:31<Plam>I can "re"activate my contact in the Open POWER foundation
10:31<Plam>(which is frankly mostly IBM)
10:31<szy_mat>Plam: don't declare my as one, yet
10:32<Plam>yeah I'm just asking :)
10:32<Plam>we contributed to some extent at the RISC-V port
10:33<szy_mat>it didn't honestly sounded any nice that OpenPOWER is mostly IBM
10:34<Plam>at least it explains why it's hard to get stuff moving forward :p
10:35<Plam>RISC-V seems to get more momentum, but it doesn't mean Xen on POWER isn't interesting anyway :)
11:01<andyhhp>the more the merrier
11:01<andyhhp>it's good for the project health
11:53-!-ChmEarl [] has joined #xen
11:53-!-ChmEarl is "Mark Pryor" on #xen ##xen-packaging #mock #packaging #virt
14:15-!-weylkesi1 [] has joined #xen
14:15-!-weylkesi1 is "weylkesiq" on #xen
14:17-!-weylkesiq [] has quit [Ping timeout: 480 seconds]
17:44-!-Netsplit <->, quits: Knorrie, ebb, SeeYou, andyhhp, Hunger, Wonka, Shados, Maxi[m], jgross, szy_mat, (+23 more, use /NETSPLIT to show all of them)
17:45-!-Netsplit over, joins: Hunger, stux|away, jjardon, alynpost, dwfreed, stsquad
17:45-!-Hunger is "EG0" on #xen #subgraph #uml #perl #OpenBSD #php #colinux #joemberek #bits
17:45-!-Netsplit over, joins: ChmEarl, zeddiii, overholts, stacktrust, sean____, evalentin
17:45-!-Netsplit <->, quits: ccw, gwd, royger, stux-
17:45-!-Netsplit <-> quits: ChmEarl, sean____, evalentin, Hunger, zeddiii, overholts, alynpost, dwfreed, stacktrust, stux|away, (+2 more, use /NETSPLIT to show all of them)
17:45-!-Netsplit over, joins: stux-, gwd, royger, ccw, evalentin, sean____, stacktrust, overholts, zeddiii, ChmEarl (+5 more)
17:45-!-Hunger is "EG0" on #xen #subgraph #uml #perl #OpenBSD #php #colinux #joemberek #bits
17:45-!-Netsplit over, joins: Hunger
17:46-!-Netsplit over, joins: gattuso, weylkesi1, szy_mat, jgross, jos2, dne, andyhhp, murb, myx_, SeeYou (+17 more)
17:48-!-XCPngXOTeam [~XCPngXOTe@2a01:240:ab08::2] has quit [Remote host closed the connection]
17:49-!-XCPngXOTeam [~XCPngXOTe@2a01:240:ab08::2] has joined #xen
17:49-!-XCPngXOTeam is "XCPngXOTeam" on #xsxoteams #xensummit #xen
21:38-!-stux- [] has quit [autokilled: Possible spambot. Mail if you think this is in error. (2022-02-17 02:38:53)]
21:46-!-stux [] has joined #xen
21:46-!-stux is "stux" on #xen #tor2web #tor-ipv6 #spi #pidgin++ #oftc #msys2 #minix-support #minix-dev #minix #loaftestbot #llvm #i2p-chat #i2p #cryptoparty #clang #ck #chrysalide #bitrig
22:07-!-jos1 [] has joined #xen
22:07-!-jos1 is "jos4" on #xen #virt #Qubes_OS #kvm #oftc #fdroid #retroshare
22:14-!-jos2 [] has quit [Ping timeout: 480 seconds]
22:23-!-jgross_ [~juergen_g@2a01:41e1:2feb:f600:3fe0:4010:3880:e6ec] has joined #xen
22:23-!-jgross_ is "realname" on #xen
22:30-!-jgross [~juergen_g@2a01:41e1:2fba:5500:8419:8f7:e72c:874f] has quit [Ping timeout: 480 seconds]
---Logclosed Thu Feb 17 00:00:16 2022