6 ms·

> They give direct access to the hardware > You're now at the mercy of the hardware manufacturer No! Read up on SR-IOV before you continue posting more misle

> They give direct access to the hardware > You're now at the mercy of the hardware manufacturer No! Read up on SR-IOV before you continue posting more misleading nonsense. https://en.wikipedia.org/wiki/Single-root_input/output_virtualization https://en.wikipedia.org/wiki/Single-root_input/output_virtu...

AshamedCaptain 1y ago
And why don't you explain what exactly you think the nonsense is rather than violating the HN guidelines with a contentless RTFM message? Your one link literally says the same thing I have said (a way to multiplex access to the bus). This is ALL about giving VMs direct access to hardware. It makes no sense to even discuss features like this otherwise. What do you think this is for if not real hardware acess? Giving VM hosts an easier time emulating Intel PRO1000 ethernet cards?
- OneDeuxTriSeiGo 1y ago
  This is a better description of what it's doing: SR-IOV: https://cdrdv2-public.intel.com/321211/pci-sig-sr-iov-primer-sr-iov-technology-paper.pdf https://cdrdv2-public.intel.com/321211/pci-sig-sr-iov-primer... S-IOV: https://cdrdv2-public.intel.com/671403/intel-scalable-io-virtualization-technical-specification.pdf https://cdrdv2-public.intel.com/671403/intel-scalable-io-vir... What they are doing is "technically" giving direct bus access, however the bus access they are giving is restricted such that the VM's accesses are all tagged and if they access anything outside the bounds they are permitted (as defined by access controls on the hardware during configuration), then you get a fault instead of the VM successfully touching anything. This is similar to how VT-d and other CPU virt extensions allow direct access to RAM but with permissioning and access control through the IOMMU. And then the other major component of SR-IOV and S-IOV is that they virtualise the interface on the PCI-E hardware itself (called virtual functions) and all of the context associated, the registers, the BAR, etc. This is akin to how VT-x and similar instructions virtualise the CPU (and registers, etc). And notably these virtual functions can be restricted via access controls, quotas, etc in hardware. So your existing VT-x extension virtualises the CPU, your existing VT-d extension virtualises the IOMMU and RAM, your existing VT-c virtualises network interfaces (but not PCI-E in general). Now SR-IOV and S-IOV virtualise the PCI-E bus w/ access control over the lanes. And now SR-IOV and S-IOV virtualise the PCI-E device hardware and their functions/interface on the bus (akin to VT-x and VT-d). Now notably S-IOV should be seen as a "SR-IOV 2.0" rather than an accompanying feature. It essentially moves the virtual function to physical function translation from the CPU or hardware in the chipset directly into the PCI-E device itself.
  - AshamedCaptain 1y ago
    I do not understand what results in this confusion. > What they are doing is "technically" giving direct bus access, however the bus access they are giving is restricted such that the VM's accesses are all tagged This is exactly what I know and what I said in my original post: a way to identify which VM is accessing what. For... giving that VM access to the hardware. > and if they access anything outside the bounds they are permitted (as defined by access controls on the hardware during configuration), then you get a fault instead of the VM successfully touching anything. Again, this is exactly what I said: you are now at the mercy of the hardware manufacturer whether there is any partitioning whatsoever. To think otherwise is wishful thinking that I do not know where it comes from. This is entirely the definition of giving the VM direct access to the hardware. There is no software-controlled emulation whatsoever going on, so you explicitly lose containment and increase your attack surface. For everything except the simplest of ethernet cards, your hardware is likely implementing this multiplexing in closed source firmware done by hardware engineers. Very likely the worst type of code ever written security-wise. > This is similar to how VT-d and other CPU virt extensions allow direct access to RAM but with permissioning and access control through the IOMMU. Not at all. Usually IOMMU is for constraining hardware that already has direct access to the RAM in the first place. > And then the other major component of SR-IOV and S-IOV is that they virtualise the interface on the PCI-E hardware itself (called virtual functions) Is this the source of the confusion? That because it is called virtual you think this virtualized somehow? It is the reason I call it partition because it is much closer to what it is (from a hw point of view). > your existing VT-x extension virtualises the CPU, your existing VT-d extension virtualises the IOMMU and RAM, your existing VT-c virtualises network interfaces (but not PCI-E in general This is meaningless because it mixes and matches everything. What does it mean to "virtualize the RAM"? RAM is already virtualized by the normal MMU, no VT-d needed at all. Hardware is the one who may require to also have its RAM access virtualized so its idea of memory matches that of the VM directly accessing hardware (instead of through a software emulation layer), and that is what benefits from an IOMMU (but does not generally require it, see GART and VT-c). But the entire point of this is again to give the VM direct access to hardware! What is it exactly that you want to refute from this?
    - 1y ago
- 0points 1y ago
  > And why don't you explain what exactly you think the nonsense is rather than violating the HN guidelines with a contentless RTFM message? Violate..? Relax, dude. You only had to read the very first sentence, but let me paraphrase: > In virtualization, single root input/output virtualization (SR-IOV) is a specification that allows the isolation of PCI Express resources for manageability and performance reasons.
  - AshamedCaptain 1y ago
    This does not imply what you think it implies. SR-IOV is about multiplexing the _bus_ itself, and offering a way for the devices to recognize which VM it is talking with. It cannot even define what devices do with this nor how they do it because _devices are a myriad_. Counterexample #1: a SRIOV ethernet card that still allows multiple domains (partitions, virtual functions, whatever) to access the same PHY (aka ethernet port). Who is doing the "bridging" here? The PCIe bus? How do you think that even remotely works? Explain to me like a 5 year old, please. Counterexample #2: a GPU with SRIOV. Each domain can still access a portion of the VRAM from the GPU. How do you think that works, if it is not the GPU itself who is doing the multiplexing? What do you think a PCIe standard even _has anything to do_ with this. How could it even have something to do? The GPU is not necessarily even exposing its entire VRAM through PCIe at all. At most, it is exposing the registers that allow you to tell how much VRAM to give each partition through a PCIe BAR. And you can tag the one for each partition with a different VF in the same way you could tag them with a different base address or literally ANYTHING. I do not understand why you (and the sibling guy) seem to think a standard for a _bus_ is even relevant to counter the argument that all of this is for VMs to make direct access to the hardware. You quote a communications standard for this hardware to be accessed by a host with multiple VMs running concurrently. This is, if anything, _even more evidence_ that this is for VMs directly accessing hardware. Again: I claim that what you're doing here is directly connecting your VMs to the hardware, where before they were not, only through a software emulation layer. You claim that this is not true, and that I couldn't be more wrong, because there is this magical interface that makes the hardware appear as if it actually was several instances. You totally miss the point: if anything, this makes your VMs _easier to directly connect to hardware_, not less. In fact, the very second sentence: > SR-IOV is commonly used in conjunction with an SR-IOV enabled hypervisor to provide virtual machines direct hardware access to network resources hence increasing its performance. And how is SR-IOV hardware going to magically appear as several interfaces, we leave that for the reader as an exercise, because you will not like the response: closed source firmware, likely an order of magnitude less reviewed than even the worst VM hardware emulator you can think of. Much more efficient, though. I am sorry, but you are not making the right argument.

AshamedCaptain 1y ago

And why don't you explain what exactly you think the nonsense is rather than violating the HN guidelines with a contentless RTFM message? Your one link literally says the same thing I have said (a way to multiplex access to the bus). This is ALL about giving VMs direct access to hardware. It makes no sense to even discuss features like this otherwise. What do you think this is for if not real hardware acess? Giving VM hosts an easier time emulating Intel PRO1000 ethernet cards?

OneDeuxTriSeiGo 1y ago
This is a better description of what it's doing: SR-IOV: https://cdrdv2-public.intel.com/321211/pci-sig-sr-iov-primer-sr-iov-technology-paper.pdf https://cdrdv2-public.intel.com/321211/pci-sig-sr-iov-primer... S-IOV: https://cdrdv2-public.intel.com/671403/intel-scalable-io-virtualization-technical-specification.pdf https://cdrdv2-public.intel.com/671403/intel-scalable-io-vir... What they are doing is "technically" giving direct bus access, however the bus access they are giving is restricted such that the VM's accesses are all tagged and if they access anything outside the bounds they are permitted (as defined by access controls on the hardware during configuration), then you get a fault instead of the VM successfully touching anything. This is similar to how VT-d and other CPU virt extensions allow direct access to RAM but with permissioning and access control through the IOMMU. And then the other major component of SR-IOV and S-IOV is that they virtualise the interface on the PCI-E hardware itself (called virtual functions) and all of the context associated, the registers, the BAR, etc. This is akin to how VT-x and similar instructions virtualise the CPU (and registers, etc). And notably these virtual functions can be restricted via access controls, quotas, etc in hardware. So your existing VT-x extension virtualises the CPU, your existing VT-d extension virtualises the IOMMU and RAM, your existing VT-c virtualises network interfaces (but not PCI-E in general). Now SR-IOV and S-IOV virtualise the PCI-E bus w/ access control over the lanes. And now SR-IOV and S-IOV virtualise the PCI-E device hardware and their functions/interface on the bus (akin to VT-x and VT-d). Now notably S-IOV should be seen as a "SR-IOV 2.0" rather than an accompanying feature. It essentially moves the virtual function to physical function translation from the CPU or hardware in the chipset directly into the PCI-E device itself.
- AshamedCaptain 1y ago
  I do not understand what results in this confusion. > What they are doing is "technically" giving direct bus access, however the bus access they are giving is restricted such that the VM's accesses are all tagged This is exactly what I know and what I said in my original post: a way to identify which VM is accessing what. For... giving that VM access to the hardware. > and if they access anything outside the bounds they are permitted (as defined by access controls on the hardware during configuration), then you get a fault instead of the VM successfully touching anything. Again, this is exactly what I said: you are now at the mercy of the hardware manufacturer whether there is any partitioning whatsoever. To think otherwise is wishful thinking that I do not know where it comes from. This is entirely the definition of giving the VM direct access to the hardware. There is no software-controlled emulation whatsoever going on, so you explicitly lose containment and increase your attack surface. For everything except the simplest of ethernet cards, your hardware is likely implementing this multiplexing in closed source firmware done by hardware engineers. Very likely the worst type of code ever written security-wise. > This is similar to how VT-d and other CPU virt extensions allow direct access to RAM but with permissioning and access control through the IOMMU. Not at all. Usually IOMMU is for constraining hardware that already has direct access to the RAM in the first place. > And then the other major component of SR-IOV and S-IOV is that they virtualise the interface on the PCI-E hardware itself (called virtual functions) Is this the source of the confusion? That because it is called virtual you think this virtualized somehow? It is the reason I call it partition because it is much closer to what it is (from a hw point of view). > your existing VT-x extension virtualises the CPU, your existing VT-d extension virtualises the IOMMU and RAM, your existing VT-c virtualises network interfaces (but not PCI-E in general This is meaningless because it mixes and matches everything. What does it mean to "virtualize the RAM"? RAM is already virtualized by the normal MMU, no VT-d needed at all. Hardware is the one who may require to also have its RAM access virtualized so its idea of memory matches that of the VM directly accessing hardware (instead of through a software emulation layer), and that is what benefits from an IOMMU (but does not generally require it, see GART and VT-c). But the entire point of this is again to give the VM direct access to hardware! What is it exactly that you want to refute from this?
  - 1y ago
0points 1y ago
> And why don't you explain what exactly you think the nonsense is rather than violating the HN guidelines with a contentless RTFM message? Violate..? Relax, dude. You only had to read the very first sentence, but let me paraphrase: > In virtualization, single root input/output virtualization (SR-IOV) is a specification that allows the isolation of PCI Express resources for manageability and performance reasons.
- AshamedCaptain 1y ago
  This does not imply what you think it implies. SR-IOV is about multiplexing the _bus_ itself, and offering a way for the devices to recognize which VM it is talking with. It cannot even define what devices do with this nor how they do it because _devices are a myriad_. Counterexample #1: a SRIOV ethernet card that still allows multiple domains (partitions, virtual functions, whatever) to access the same PHY (aka ethernet port). Who is doing the "bridging" here? The PCIe bus? How do you think that even remotely works? Explain to me like a 5 year old, please. Counterexample #2: a GPU with SRIOV. Each domain can still access a portion of the VRAM from the GPU. How do you think that works, if it is not the GPU itself who is doing the multiplexing? What do you think a PCIe standard even _has anything to do_ with this. How could it even have something to do? The GPU is not necessarily even exposing its entire VRAM through PCIe at all. At most, it is exposing the registers that allow you to tell how much VRAM to give each partition through a PCIe BAR. And you can tag the one for each partition with a different VF in the same way you could tag them with a different base address or literally ANYTHING. I do not understand why you (and the sibling guy) seem to think a standard for a _bus_ is even relevant to counter the argument that all of this is for VMs to make direct access to the hardware. You quote a communications standard for this hardware to be accessed by a host with multiple VMs running concurrently. This is, if anything, _even more evidence_ that this is for VMs directly accessing hardware. Again: I claim that what you're doing here is directly connecting your VMs to the hardware, where before they were not, only through a software emulation layer. You claim that this is not true, and that I couldn't be more wrong, because there is this magical interface that makes the hardware appear as if it actually was several instances. You totally miss the point: if anything, this makes your VMs _easier to directly connect to hardware_, not less. In fact, the very second sentence: > SR-IOV is commonly used in conjunction with an SR-IOV enabled hypervisor to provide virtual machines direct hardware access to network resources hence increasing its performance. And how is SR-IOV hardware going to magically appear as several interfaces, we leave that for the reader as an exercise, because you will not like the response: closed source firmware, likely an order of magnitude less reviewed than even the worst VM hardware emulator you can think of. Much more efficient, though. I am sorry, but you are not making the right argument.