[14:00] Welcome to the Linux Plumbers Conference 2020 Microconference2/Virtual-Room!

Please remember that the LPC anti-harassment policy applies to interaction in this room, and that this room is being recorded.

Please keep your microphone muted and your video off except when participating in the discussion.

This server is running BigBlueButton. [14:03] Ashok Raj : Hi Lorenzo! [14:04] Marc Zyngier : hi guys. [14:05] Marc Zyngier : got in early to make sure my setup was working. [14:09] Ashok Raj : Hi Sergei.. Saw you waving :-) [14:16] YouTube Live : This meeting is streaming live on YouTube [14:29] Bjorn Helgaas : Lorenzo, your mic sounds really good except for a little popping, just fyi [14:29] Ashok Raj : and Bjorn.. where are you hiding :-) [14:47] Baolu Lu : The camera sharing doesn't work on my end. Sorry about that. [14:47] Baolu Lu : The camera sharing doesn't work on my end. Sorry about that. [14:54] Marc Zyngier : and my laptop is pretty toasty!!! [14:58] Bjorn Helgaas : in these times when we can't be in person, it is *very* nice to at least see all these friendly faces, so i'll be sorry to see all the cams go ;) [14:58] Krzysztof Wilczyński : It was, indeed :-) [14:58] Thomas Gleixner : yeah, just for people with stoneage internet connectivity it sucks :) [14:59] Marc Zyngier : @Bjorn: agreed. one day, we'll be back to normal... [15:00] Peter Teoh : you are breathing into microphone and making lots of noises. [15:01] Lorenzo Pieralisi : https://chat.2020.linuxplumbersconf.org/channel/vfio-iommu-pci-mc [15:01] Lorenzo Pieralisi : Chat root ^^^^^ [15:01] Lorenzo Pieralisi : s/root/room [15:11] Jonathan Cameron : Should be careful not to be qemu specific given other options in that space. [15:21] Ian Forbes : volume [15:21] Donald Dutile : nope [15:22] Ashok Raj : no. still weak.. speak louder [15:22] Alex Williamson : bof sessions @7pm PDT today or regular conf times thur/fri [15:23] Jason Gunthorpe : Oh I'm not in PDT, 7pm is too late at night [15:24] Alex Williamson : are the hack rooms available 24x7? maybe we can grab one at the end of the schedule today [15:24] Thomas Gleixner : can't hear anything [15:25] Donald Dutile : Alex: Jason +4 PDT (+1 EST)... [15:27] Alexandru Elisei : @Thomas: volume is very low for me, increasing the volume fixed it. [15:28] Krzysztof Wilczyński : I boosted my volume up to compensate, I wonder if Yi needs to raise microphone boost in his volume settings. [15:28] Jonathan Cameron : Yi tried. Couldn't solve so we moved on. [15:28] Jonathan Cameron : (tried to fix it, not sure how!) [15:28] Krzysztof Wilczyński : No worries :) [15:29] Thomas Gleixner : @Alexandru: 100% and still just mumbling :) [15:29] Jonathan Cameron : Get a bigger amplifier :) [15:29] Alex Williamson : it goes to 11 ;) [15:31] Jonathan Cameron : ow. Lorenzo. That hurt. [15:32] Ashok Raj : 11 EST? need to get the timezone :-) [15:34] Alex Williamson : Ashok, just showing my age with a Spinal Tap reference ;) [15:35] Marc Zyngier : who doesn't *love* a good ST reference? [16:02] Jacob Pan : Joerg, what is a good time to have more discussions on IOASID? [16:02] Alex Williamson : @Lorenzo et al, great job on the shared notes [16:04] Thomas Gleixner : @Jason: using buslock around affinity (mostly proc/irq/...) turned out to be trivial thankfully, so you should be all set [16:10] Jörg Rödel : @Jacob, I would prefer tomorrow, which timezone are you in? [16:12] Lorenzo Pieralisi : @Jonathan: what hurts :D ? [16:12] Jacob Pan : I am in PST [16:12] Lorenzo Pieralisi : @Alex: thanks ! [16:13] Alex Williamson : @Lorenzo, I think it was when we all had our volume turned up to hear Yi and you interjected at a normal volume [16:14] Jörg Rödel : @Jacob: Okay, than today might be better, lets try to grad a hackroom after we're done with the microconference today [16:15] Jonathan Cameron : @Alex and @Lorenzo. Exactly that! Threw the headphones across the room :) [16:15] Jacob Pan : @Joerg sounds good, how about hackroom #3, random number [16:15] Christina Quast : Just one comment about the last talk: is a function, that is called `*set_get` a good name? [16:16] Jörg Rödel : @Jacob: Sounds good, lets try that [16:16] Jacob Pan : @Joerg ttyl [16:17] Jacob Pan : @Christina I agree not a good name. Just to keep the ioasid_set name so that people can see where it came from. [16:27] Len Brown : isn't it that BOTH must be trusted? [16:27] Oliver O'Halloran : pretty much [16:31] Will Deacon : so it sounds like a boolean flag is not sufficient to express what we need, and the word "trust" is probably best avoided? [16:31] Bjorn Helgaas : i think the "untrusted" name was a mistake [16:32] Will Deacon : I agree [16:32] Oliver O'Halloran : maybe, i think there's space for a concept on an explicitly untrustworthy device, but conflating that with external devices is a mistake [16:32] Mickaël Salaün : Why not distrust all devices by default (and let the user trust some of them)? Is there performance issues enabling IOMMU for some devices? [16:33] Jörg Rödel : The question is what we are doing with these multiple levels of untrust [16:33] Jonathan Cameron : Is it better to provide separate controls for what is actually being restricted? Mapping those to user friendly names can be a problem for higher level software. [16:33] Ashok Raj : @bjorn Agree. The spec said external_device, we shouldn't have named it untrusted to begin with. [16:33] Jonathan Cameron : @ Mickaël yes huge performance penalty for some types of device. [16:33] Oliver O'Halloran : what spec? [16:33] Will Deacon : Joerg: yes, especially as Robin mentioned perhaps not even binding a driver to some devices (iiuc) [16:34] Jörg Rödel : Will, yes, that is what's left. Untrusted devices already get translated and for VT-d even bounce buffered [16:34] Jörg Rödel : The bounce buffer should be generalized [16:34] Jonathan Cameron : @Mickaël As Robin mentioned we also have question of how strictly we use the iommu (basically do we do lazy invalidates) [16:34] Ashok Raj : @oliver, let me post it once i find [16:36] Robin Murphy : yeah, if anyone wants to wire up the bounce pages stuff for iommu-dma please give it a go - it shouldn't be *too* hard (famous last words)... :) [16:36] Sathyanarayanan Kuppuswamy Natarajan : Concept of trusted/un-trusted is applicable to non-PCI devices as well. So should this be considered at struct device level ? [16:36] Mickaël Salaün : @Jonathan: does it depends of the devices (manufacturer) or the bandwidth required (e.g. network card, drives)? If so, I guess all low-bandwidth devices could be marked as untrusted right? [16:36] Oliver O'Halloran : probably [16:37] Jörg Rödel : Robin: Bouncing should only be necessary when mappings are not page-aligned in address and size, so this can be an optimization [16:37] Jonathan Cameron : @Mickaël How do you known in general that a device is low bandwidth? Latency can also be an issue btw + jitter and other such measures. [16:37] Oliver O'Halloran : it's worth pointing out that enforcing strict iommu behaviour (and bounce buffering) only stops the device from looking at system memory. if the untrustworthy device impersonates a device with an exploitable driver we're still screwed [16:37] Oliver O'Halloran : so yeah, you need some extra mechanism for preventing binding [16:39] Robin Murphy : @Oliver exactly, hence the need for finer-grained degrees of "trust" [16:40] Oliver O'Halloran : yep, but what are the degrees and what's the userspace interface for controlling those? :) [16:41] Björn Töpel : Yup! [16:41] Alexandru Elisei : I can hear you! :) [16:41] Will Deacon : Loud and clear1 [16:41] Boaz Harrosh : its too hi please lower the mic volum [16:42] Boaz Harrosh : Gain to high on MIC [16:42] David Mc Lean : can anyone see the graphics he is pointing to? [16:43] Alexandru Elisei : Yes, I can see it [16:43] Oliver O'Halloran : yep,. works here [16:43] Sathyanarayanan Kuppuswamy Natarajan : yes [16:43] David Mc Lean : Thanks [16:47] Rajat Jain : Even I can't see [16:47] Alex Williamson : @david perhaps click the restore presentation circle in the bottom right [16:47] Alex Williamson : @rajat ^^^ [16:51] Rajat Jain : Thanks, it works now [17:00] Ashok Raj : @oliver https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports [17:01] Oliver O'Halloran : ta [17:08] Rajat Jain : Note that it specifies 2 properties that can be used: "External-facing" (for external facing ports) and "DmaProperty" (for internal facing ports) [17:08] Oliver O'Halloran : @sergei, have you seen any problems with network devices when doing bus renumbering? a constant problem we have is that if the numbers change in firmware it breaks everyone's network config [17:08] Oliver O'Halloran : (thanks systemd) [17:10] Rajat Jain : But both of the properties above can only be specified at the root port level (can't be used to protect any random device in the hierarchy). [17:11] Ashok Raj : @oliver, there is another pci spec that tries to address that with establishing identity. Like the Component Measurement and Authentication (CMA ECN). not sure if we can do much about that until we have devices and framework that support that [17:13] Sergei Miroshnichenko : For now, udev doesn't yet notice that devices was renamed in runtime, so network interfaces don't get renamed as well. Until a reboot [17:14] Oliver O'Halloran : sounds a little fragile [17:14] Oliver O'Halloran : @ashok, doesn't do us much good considering the vast majority of NICs in the wild don't support that and never will. oh well. [17:17] Ashok Raj : @oliver, you are right about that.. there is only so much we can do with legacy. So we might need to keep some user space driven for legacy devices since there is no easy way to establish trust worthyness. [17:22] Oliver O'Halloran : sorry, i thought you were talking about the NIC renaming thing. [17:22] Oliver O'Halloran : yeah i'm aware of CMA. authenticated devices was the other use-case I was thinking of for untrusted internal devices since we could make everything untrusted by default unless we can establish its identity via CMA [17:39] Rajat Jain : CMA is the future though, how do we deal with platforms and devices at hand is the question. [17:39] Jörg Rödel : Isn't there a check function for ATS which a driver could use? [17:40] Baolu Lu : pci_ats_enabled()? [17:40] Jörg Rödel : Right, that's it [17:41] Baolu Lu : it's from device side, driver has no idea whether the iommu has support. [17:49] Vaibhav Gupta : We are working on to remove the use of pci_restore_state() in resume callback, from the drivers. [17:51] Baolu Lu : so how the features like ats get restored? [17:52] Vaibhav Gupta : Well i am not sure about ats specifically but the PCI core calls the pci_restore_state() . So it should restore the std config registers. [17:53] Baolu Lu : okay, thanks! [17:53] Ashok Raj : @Vaibhav, the way pci handles these extended capability save/restore needs some cleanup as well.. appears a bit hacky to me [17:54] Vaibhav Gupta : To add on, only the drivers using legacy power management framework invoke pci_restore_state() during resume. Or maybe *some* generic ones. But since its the [17:55] Vaibhav Gupta : but it is the job of pci core [17:55] Oliver O'Halloran : there's a few drivers that use it in their error recovery callbacks too [17:55] Oliver O'Halloran : i'm not convinced saving the device state after an error is a good idea, but that's what they do [17:55] Oliver O'Halloran : and the pci core doesn't really offer any alternatives [17:57] Vaibhav Gupta : @Ashok, if we first remove the dependency of PCI drivers on PCI helper functions, where ever possible, it should simplify many things. [18:05] Sathyanarayanan Kuppuswamy Natarajan : yes [18:13] Baolu Lu : vt-d driver maps sc lists into a single iova range [18:14] Baolu Lu : /sc/sg/ [18:16] Ashok Raj : @Tom_Murphy... Yes this is very useful.. Thanks for doing it. [18:18] Baolu Lu : previously we have home-make private domain in vt-d driver which is a block issue. We have fixed this since v5.8. [18:18] Ashok Raj : @Gosh... I just got confused why the 2 Mutphy's sound different :-) [18:20] Robin Murphy : Tom's a proper Irishman, me not so much ;) [18:20] Ashok Raj : Baolu... [18:21] Baolu Lu : @Tom Murphy thanks for your great help, i can hand over and get this work move on... [18:22] Tom Murphy : @Baolu Lu Thank you [18:24] Baolu Lu : you are welcome~ [18:25] Salil Mehta : Thanks for sharing. Nice presentation! Let us get in touch with respect to this... [18:39] Jacob Pan : @Jonathan Derrick, If subdevice MSI is 1:1 mapped into VMD MSI table, can it use posted interrupt then? [18:46] Ashok Raj : @Jacob I asked the exact same question, but it seems there is some HW that blocks interrupts from the sub-device.. we should follow up offline [18:49] Jacob Pan : @Ashok, sounds good. I thought the subdev MSI still results in VMD MSI, just need to be dispatched. Anyway, we can follow up. [18:59] Konrad Wilk : And OASIS [18:59] Konrad Wilk : Since OASIS is the one that does that the VirtIO specifications [19:00] Cornelia Huck : yes [19:01] Jörg Rödel : @Jacob: Joined Hackroom 3 [19:01] Ashok Raj : @Kishon, with all these experiments, do you use the IOMMU, or that't not in the path yet? [19:01] Cornelia Huck : I'll take a look at the RFC [19:01] David Woodhouse : We don't need to finish on the dot of 18:00 UTC. We don't have hotel staff chasing us out of the rooms this year :) [19:02] Ashok Raj : @DavidW... :-) [19:02] Alex Williamson : @Lorenzo, thanks for the moderating, great job! [19:02] Bjorn Helgaas : thanks very much to everybody, this was very useful [19:03] Jerry Snitselaar : thanks [19:03] Jonathan Cameron : @Lorenzo. Thanks! [19:03] Cornelia Huck : thanks everyone! [19:03] Jacob Pan : Thank you! [19:03] Kishon Vijay Abraham I. : @Ashok, haven't used the IOMMU yet (the IOMMU will be only in the RC). EP should be transparent to if RC provides a IOMMU translated address or not [19:03] Baolu Lu : Thanks, bye! [19:04] Kishon Vijay Abraham I. : @Ashok do you suspect any issues to come