Re: [Xen-devel] RFC: Still TODO for 4.2?

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
> On Thu, Jan 19, 2012 at 8:35 AM, Jan Beulich <JBeulich@xxxxxxxx>
> wrote:
>         >>> On 17.01.12 at 10:09, "Jan Beulich" <JBeulich@xxxxxxxx>
>         wrote:
>         >>>> On 16.01.12 at 14:39, Ian Campbell
>         <Ian.Campbell@xxxxxxxxxx> wrote:
>         >> On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
>         >>> >>> On 04.01.12 at 17:29, Ian Campbell
>         <Ian.Campbell@xxxxxxxxxx> wrote:
>         >>> > What are the outstanding things to do before we think we
>         can start on
>         >>> > the 4.2 -rc's? Does anyone have a timetable in mind?
>         >>> >
>         >>> > hypervisor:
>         >>> >
>         >>> >       * ??? - Keir, Tim, Jan?
>         >>>
>         >>> Apart from a few small things that I have on my todo list,
>         the only
>         >>> bigger one (at least from an possible impact perspective)
>         is the
>         >>> round-up of the closing of the security hole in MSI-X
>         passthrough
>         >>> (uniformly - i.e. even for Dom0 - disallowing write access
>         to MSI-X
>         >>> table pages), which I intended to do only once the
>         upstream qemu
>         >>> patch series also incorporates the respective recent
>         qemu-xen
>         >>> change.
>         >>
>         >> It sounds like this issue is a blocker for the release,
>         whereas the
>         >> upstream qemu support for pci passthrough is not
>         necessarily. Has your
>         >> precondition for inclusion been met yet or do we need to
>         prod someone?
>         >
>         > Just for reference, below the intended (trivial) change.
>         
>         
>         As unfortunate as it is - I just found that the security hole
>         is all but
>         closed, due to xen/arch/x86/hvm/vmsi.c:msixtbl_write() writing
>         whatever the guest specified into the 3rd word of each MSI-X
>         table
>         entry. There is also another hypervisor data corrupting flaw
>         in that
>         code; I'm in the process of putting together a patch, but will
>         (again)
>         need someone with suitable hardware to test this.
>         
>         Jan
>         
>         
>         _______________________________________________
>         Xen-devel mailing list
>         Xen-devel@xxxxxxxxxxxxxxxxxxx
>         http://lists.xensource.com/xen-devel
>         
> 
> 
> I do have a set of initial patches for xl remus. Since the "script="
> support doesnt exist for disk configurations (required to support both
> DRBD and tapdisk backends).
> 
> So, currently I only have memory checkpointing functionality. No disk
> buffering.
> Will submit it in a day or so.
> 
> About network buffering:
> a.  There is code to install and manipulate the network buffer via
> netlink messages. And its in python. While the "xl remus" control flow
> starts off from C. Either I implement the C equivalent
> of the python code or call the python code from C (this is C->python
> and not the other way around). Please correct me if I am wrong.

Wrong about what?

I don't think calling Python from C in libxl is a good idea. Forking a
process would be better but best would be to just implement the C
version. Is there a libnetlink which can help with this sort of thing?

> b. The kernel module (sch_plug):  Last I knew, the network
> buffering module (sch_plug) was in the pvops tree (2.6.* series). When
> the tree moved to 3.0 series, it got axed off.

My understanding was that a competing module with similar/equivalent
functionality was the one which eventually made it upstream (I don't
know the names). Unfortunately this probably means that Remus needs to
switch over to the upstreamed thing.

There is no "Xen Linux tree" like there used to be and we wouldn't want
to carry a module which isn't ready for upstream in any case. (Your
module wasn't axed, it just wasn't/isn't upstream).

> While I am still, convincing the netdev folks into accepting this
> module upstream, I  have a link in the remus wiki, asking people to
> download/compile the module. (People do this only after shooting a
> couple of "Remus is not working" emails to the mailing list)

You can't detect this at runtime and print an error message? Do you not
get ENOSYS or something when you try and use the module?

>  As an alternative, I could pull it into the tools/remus/ folder (just
> like the way it used to be before the pvops kernels) and compile it as
> part of the tools compilation process. 

The build doesn't include building a kernel any more so I don't think
this will work.

> But as starters, people would be able to play with remus via xl (just
> memory checkpointing).
> What do you folks think?

I think it would be a good start to get just that bit in, as you say
people can play with it and it also lays the groundwork for the rest.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel