Re: [Xen-devel] [XEN][RFC PATCH V2 05/17] hvm: Modify hvm_op

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 08/24/2012 04:38 PM, Jan Beulich wrote:
> > > > On 23.08.12 at 12:52, Julien Grall<julien.grall@xxxxxxxxxx>  wrote:
> > > >          
> > On 08/23/2012 08:27 AM, Jan Beulich wrote:
> >      
> > > > switch ( a.index )
> > > > {
> > > > -            case HVM_PARAM_IOREQ_PFN:
> > > >
> > > >          
> > > Removing sub-ops which a domain can issue for itself (which for this and
> > > another one below appears to be the case) is not allowed.
> > >
> > >        
> > I removed these 3 sub-ops because it will not work with
> > QEMU disaggregation. Shared pages and event channel
> > for IO request are private for each device model.
> >      
> Then they need to be made inaccessible for that specific setup, not
> removed altogether.
>
>    
What do you mean by specific feature ?
With this patch series, you are able to handle one or more
QEMU.
Keep a compatibility with the old IO emulation is hard.
It's still possible but IOreq handle will not send an IOreq
if no device  models registered it. There is no more default QEMU.

I have send a long patch series for QEMU, but it's for supporting
a "full disaggregation" (i.e. multiple QEMU for domain).
If you want to handle only one QEMU the patch decrease to
only 100 lines. So it can be backported easily.

> > > > +            case HVM_PARAM_IO_PFN_FIRST:
> > > >
> > > >          
> > > I don't see where in this patch this and the other new sub-op constants
> > > get defined.
> > >
> > >        
> > Both sub-op constants are added in patch 1:
> > http://lists.xen.org/archives/html/xen-devel/2012-08/msg01767.html
> >      
> Hmm, I can certainly see reasons for breaking up things that way,
> but I generally prefer patches to represent functional units.
>    
I will rework my patch series to represen function units.

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel