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.
Regards,
Jason
