Re: hardware domain and control domain separation

[Jason Andryuk <jason.andryuk@xxxxxxx>]

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.
A PV backend not servicing a request is interference, but it doesn't 
block the frontend domain or vcpu.  The primitives don't block, so 
drivers can be written to handle the lack of a response.  As you note, 
this can't be a critical service for the domain.
Regards,
Jason