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

[Shriram Rajagopalan <rshriram@xxxxxxxxx>]

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.

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.

 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)

 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. 

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

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