[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.