On 26.06.2025 23:18, Jason Andryuk wrote: > On 2025-06-25 01:32, Jan Beulich wrote: >> On 24.06.2025 22:14, Jason Andryuk wrote: >>> On 2025-06-24 01:25, Jan Beulich wrote: >>>> On 24.06.2025 00:51, Stefano Stabellini wrote: >>>>> On Mon, 23 Jun 2025, Demi Marie Obenour wrote: >>>>>> On 6/23/25 11:44, Jan Beulich wrote: >>>>>>> On 21.06.2025 02:41, Stefano Stabellini wrote: >>>>>>> Also a more fundamental question I was wondering about: If Control had >>>>>>> full privilege, nothing else in the system ought to be able to interfere >>>>>>> with it. Yet then how does that domain communicate with the outside >>>>>>> world? It can't have PV or Virtio drivers after all. And even if its >>>>>>> sole communication channel was a UART, Hardware would likely be able to >>>>>>> interfere. >>>>> >>>>> There are well-established methods for implementing domain-to-domain >>>>> communication that are free from interference, such as using carefully >>>>> defined rings on static shared memory. I believe one of these techniques >>>>> involves placing the indexes on separate pages and mapping them >>>>> read-only from one of the two domains. >>>> >>>> How's that going to help with the backend refusing service, which I view >>>> as one "method" of interference? Or else, what exactly does "interference" >>>> mean in this context? (More generally, I think it is necessary to very >>>> clearly define terminology used. Without such, words can easily mean >>>> different things to different people.) >>> >>> Yes, there are different kids of interference. We are concerned about a >>> domain blocking another domain. The main example is an ioreq blocking a >>> vCPU. The blocked domain is unable to recover on its own. >> >> On which insns an ioreq server may kick in can be well known. A kernel >> can therefore, in principle, come with recovery code, just like it can ... > > The case I am thinking of is QEMU providing a virtio device to a domain. > The domain has to write to a MMIO area in a BAR to notify QEMU. From > my understanding, that vCPU is blocked in Xen until QEMU responds to the > ioreq. I don't see how any recovery code is possible, but I may be > missing something.
Hmm, yes, no idea now what I was thinking when I wrote the earlier reply. Jan
