Re: RFC: Still TODO for 4.2?

Re: RFC: Still TODO for 4.2?

[Jan Beulich]

>>> On 16.01.12 at 14:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
>> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> 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.

Jan

This continues to leave unaddressed the case where PV guests map the
MSI-X table page(s) before setting up the first MSI-X interrupt (see
the original c/s 22182:68cc3c514a0a description for options).

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -869,7 +869,7 @@ get_page_from_l1e(
             return -EINVAL;
         }
 
-        if ( !(l1f & _PAGE_RW) || IS_PRIV(pg_owner) ||
+        if ( !(l1f & _PAGE_RW) ||
              !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
             return 0;
         dprintk(XENLOG_G_WARNING,

Re: RFC: Still TODO for 4.2?

[Jan Beulich]

>>> On 17.01.12 at 10:09, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 16.01.12 at 14:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
>>> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> 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

Re: RFC: Still TODO for 4.2?

[Shriram Rajagopalan]

[-- Attachment #1.1: Type: text/plain, Size: 3268 bytes --]

On Thu, Jan 19, 2012 at 8:35 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 17.01.12 at 10:09, "Jan Beulich" <JBeulich@suse.com> wrote:
> >>>> On 16.01.12 at 14:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
> >>> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com>
> 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@lists.xensource.com
> 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

[-- Attachment #1.2: Type: text/html, Size: 4387 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: RFC: Still TODO for 4.2?

[Ian Campbell]

On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
> On Thu, Jan 19, 2012 at 8:35 AM, Jan Beulich <JBeulich@suse.com>
> wrote:
>         >>> On 17.01.12 at 10:09, "Jan Beulich" <JBeulich@suse.com>
>         wrote:
>         >>>> On 16.01.12 at 14:39, Ian Campbell
>         <Ian.Campbell@citrix.com> wrote:
>         >> On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
>         >>> >>> On 04.01.12 at 17:29, Ian Campbell
>         <Ian.Campbell@citrix.com> 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@lists.xensource.com
>         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.

Re: RFC: Still TODO for 4.2?

[Shriram Rajagopalan]

On 2012-01-19, at 9:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
>> 
>> 
>> 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?
> 

There is. And it's in the tools tree (tools/python/xen/lowlevel/netlink/)

Just that it's bit cryptic and the netlink.py module makes things easy.
>> 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.
> 

I don't think so. When I submitted the patch for sch_plug to netdev, nobody (even the qdisc maintainer) mentioned anything about an equivalent module.


> 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?

I do. And the emails are despite that. 
> 
>> 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 can we at least include the source, make file and a readme telling people to install the required packages needed to compile a module.

> 
>> 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.
> 
> 

Re: RFC: Still TODO for 4.2?

[Konrad Rzeszutek Wilk]

On Thu, Jan 19, 2012 at 11:00:19AM -0800, Shriram Rajagopalan wrote:
> On 2012-01-19, at 9:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
> >> 
> >> 
> >> 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.

Were the disk buffering implemented in kernel? As a dm-* device or
through blktap (which is not maintained)?

Re: RFC: Still TODO for 4.2?

[Ian Campbell]

On Thu, 2012-01-19 at 19:00 +0000, Shriram Rajagopalan wrote:
> On 2012-01-19, at 9:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
> >> 
> >> 
> >> 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?
> > 
> 
> There is. And it's in the tools tree (tools/python/xen/lowlevel/netlink/)

I meant an existing generic netlink library, not something specific to
the Xen python bindings.

Debian has libnl{1,2,3} pacakges in it -- why not use them? 

There is no reason why this sort of generic library should be in the Xen
tree. (lets be honest, there's no reason why the python bindings to such
a library should be in Xen either)

> Just that it's bit cryptic and the netlink.py module makes things easy.

Calling into python from libxl is not acceptable.

> >> 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.
> > 
> 
> I don't think so. When I submitted the patch for sch_plug to netdev,
> nobody (even the qdisc maintainer) mentioned anything about an
> equivalent module.

I must have been mistaken then. Why is your module not upstream?

> > 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?
> 
> I do. And the emails are despite that. 

It sounds like there would be no helping these people.
 
> >> 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 can we at least include the source, make file and a readme telling
> people to install the required packages needed to compile a module.

We are trying to get out of the business of bundling every bit of
infrastructure which someone happens to want to use with Xen in the Xen
source repository, so, no, I don't think we can/should include the
source to this Linux kernel module in the Xen tree.

You could perhaps add a README or some Remus documentation directing
people to an external tarball with the module in it, but from what you
say above it doesn't sound like that will help very much (and neither
would having that tarball in the tree).

Of course the right solution is to get your module merged upstream.

Ian.

Re: RFC: Still TODO for 4.2?

[Shriram Rajagopalan]

[-- Attachment #1.1: Type: text/plain, Size: 1645 bytes --]

On Thu, Jan 19, 2012 at 12:42 PM, Konrad Rzeszutek Wilk
<konrad@darnok.org>wrote:

> On Thu, Jan 19, 2012 at 11:00:19AM -0800, Shriram Rajagopalan wrote:
> > On 2012-01-19, at 9:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >
> > > On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
> > >>
> > >>
> > >> 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.
>
> Were the disk buffering implemented in kernel? As a dm-* device or
> through blktap (which is not maintained)?
>
>
Blktap2 - userspace (block-remus.c driver). It just needs a hostname and
port
number to replicate disk writes to. The main remus control loop
communicates with it
via fifos.

DRBD - kernel module (separate source tree. not the mainline one). And
remus communicates
with it via ioctls (so easy in libxl).

The current xl disk specs dont support the script format or such
extensions, though which
such parameters could be accepted and supplied to the tapdisk2 module
(which in turn
loads block-remus driver).

The DRBD backend is also simple. The block-drbd script (in etc/xen/scripts)
does all the drbd vodoo stuff
of setting up the drbd resources.

In the worst case, one could simply use tap2:/dev/drbd1 (where /dev/drbd1
is the device exported
by drbd) and in the libxl code, i could strncmp(disk_name,"/dev/drbd",9)
and enable the disk buffering,
leaving the responsibility of manually setting up drbd to the user.

[-- Attachment #1.2: Type: text/html, Size: 2174 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: RFC: Still TODO for 4.2?

[Shriram Rajagopalan]

[-- Attachment #1.1: Type: text/plain, Size: 4769 bytes --]

On Thu, Jan 19, 2012 at 1:10 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Thu, 2012-01-19 at 19:00 +0000, Shriram Rajagopalan wrote:
> > On 2012-01-19, at 9:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >
> > > On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
> > >>
> > >>
> > >> 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?
> > >
> >
> > There is. And it's in the tools tree (tools/python/xen/lowlevel/netlink/)
>
> I meant an existing generic netlink library, not something specific to
> the Xen python bindings.
>
> Debian has libnl{1,2,3} pacakges in it -- why not use them?
>
>
Yes I know. I have toyed with them. The qdisc names are hardcoded in their
libraries.
So, even if one installs sch_plug (qdisc name "plug"), the library wont
recognize it!
I do have my own version of the library (patched) but as you said, I dont
want to
bundle that stuff with xen.

There is no reason why this sort of generic library should be in the Xen
> tree. (lets be honest, there's no reason why the python bindings to such
> a library should be in Xen either)
>
> Just that it's bit cryptic and the netlink.py module makes things easy.
>
> Calling into python from libxl is not acceptable.
>
>
I understand. I wouldnt have done it either :)

 > >> 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.
> > >
> >
> > I don't think so. When I submitted the patch for sch_plug to netdev,
> > nobody (even the qdisc maintainer) mentioned anything about an
> > equivalent module.
>
> I must have been mistaken then. Why is your module not upstream?
>
>
Beats me.


> > > 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?
> >
> > I do. And the emails are despite that.
>
> It sounds like there would be no helping these people.
>
> > >> 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 can we at least include the source, make file and a readme telling
> > people to install the required packages needed to compile a module.
>
> We are trying to get out of the business of bundling every bit of
> infrastructure which someone happens to want to use with Xen in the Xen
> source repository, so, no, I don't think we can/should include the
> source to this Linux kernel module in the Xen tree.
>
> You could perhaps add a README or some Remus documentation directing
> people to an external tarball with the module in it, but from what you
> say above it doesn't sound like that will help very much (and neither
> would having that tarball in the tree).
>
> Of course the right solution is to get your module merged upstream.
>
> Ian.
>
>

[-- Attachment #1.2: Type: text/html, Size: 6734 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: RFC: Still TODO for 4.2?

[Ian Campbell]

On Thu, 2012-01-19 at 21:30 +0000, Shriram Rajagopalan wrote:
> On Thu, Jan 19, 2012 at 1:10 PM, Ian Campbell 
>         Debian has libnl{1,2,3} pacakges in it -- why not use them?
>         
> 
> Yes I know. I have toyed with them. The qdisc names are hardcoded in
> their libraries. So, even if one installs sch_plug (qdisc name
> "plug"), the library wont recognize it! I do have my own version of
> the library (patched) but as you said, I dont want to bundle that
> stuff with xen.

Why don't you send said patch to the libnl upstream? I'm sure once the
kernel module is in they will be interested in such a patch.

>         I must have been mistaken then. Why is your module not
>         upstream?
>         
>         
> 
> Beats me.

Did you send it more than once?

According to http://patchwork.ozlabs.org/patch/132315/ it is in state
"changes requested". There is a longish thread attached to the posting
so I assume it is something in there.

Just like with submitting patches to Xen you need to address any review
comments and resend patches, ping people etc, it's not just a case of
firing and forgetting a patch on a mailing list.

Ian.

Re: RFC: Still TODO for 4.2?

[Pasi Kärkkäinen]

On Fri, Jan 06, 2012 at 11:37:14AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 04, 2012 at 01:57:28PM -0600, Wei Huang wrote:
> > On 01/04/2012 01:43 PM, Pasi K?rkk?inen wrote:
> > >On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:
> > >>>>Has anybody got anything else? I'm sure I've missed stuff. Are there any
> > >>>>must haves e.g. in the paging/sharing spaces?
> > >>>>
> > >>>- What's the status of Nested Hardware Virtualization?
> > >>>I remember some email saying Intel vmx-on-vmx has some performance 
> > >>>issues,
> > >>>and amd svm-on-svm works better..
> > >>>
> > >>>
> > >>>- Also there's a bunch of VGA passthru related patches,
> > >>>that I once volunteered to collect/rebase/cleanup/repost myself,
> > >>>but I still haven't had time for that :(
> > >>Since there were quite a lot of interest on this subject, should we
> > >>document it in a separate wiki for working combinations (like
> > >>hypervisor, dom0, gfx card, driver version, tricks, etc)?
> > >>
> > >I actually once started writing down that kind of stuff:
> > >http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html
> > >
> > >Feel free to contribute :)
> > >
> > >There's also:
> > >http://wiki.xen.org/xenwiki/XenVGAPassthrough
> > Thanks for sharing. I will contribute my findings as needed. BTW, do you 
> > need my VBIOS loading patches (sent long time ago) for AMD GPU? It is a 
> 
> Yes! Thought I haven't figured out yet how to extract the AMD GPU BIOS
> from the card. I've been able to pass in a Radeon 4870 to an Win 7 HVM
> guest and it works nicely.. the first time. After I shut down the guest
> it just never works again :-(
> 

Hmm.. I wonder if this would work:

cd /sys/bus/pci/devices/0000:01:05.0
sudo sh -c "echo 1 > rom"
sudo sh -c "cat rom > ~/bios.rom"


-- Pasi

Re: RFC: Still TODO for 4.2?

[Andres Lagar-Cavilla]

> Date: Mon, 16 Jan 2012 13:39:27 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: Jan Beulich <JBeulich@suse.com>
> Cc: "Keir \(Xen.org\)" <keir@xen.org>, "Tim \(Xen.org\)"
> 	<tim@xen.org>,	xen-devel <xen-devel@lists.xensource.com>,	Ian Jackson
> 	<Ian.Jackson@eu.citrix.com>,	Stefano Stabellini
> 	<Stefano.Stabellini@eu.citrix.com>
> Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
> Message-ID: <1326721167.17210.449.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
>> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> 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?
Insofar paging/sharing for 4.2:
- mem event ring management posted, seems close to going in.
- I would love to have wait queue support for paging, which Olaf is
working on.
- Just posted sharing patches.
- A long standing issue is a fully synchronized p2m (locking lookups),
which is something I'll look into as all of the above becomes resolved.

Thanks,
Andres
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 16 Jan 2012 13:42:49 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
> Cc: xen-devel <xen-devel@lists.xensource.com>,	"Keir \(Xen.org\)"
> 	<keir@xen.org>,	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,	Ian
> 	Jackson <Ian.Jackson@eu.citrix.com>, "Tim	\(Xen.org\)" <tim@xen.org>,
> 	Jan Beulich <JBeulich@suse.com>
> Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
> Message-ID: <1326721369.17210.452.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, 2012-01-04 at 16:51 +0000, Stefano Stabellini wrote:
>> On Wed, 4 Jan 2012, Konrad Rzeszutek Wilk wrote:
>> > On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
>> > >       * Integrate qemu+seabios upstream into the build (Stefano has
>> > >         posted patches, I guess they need refreshing and reposting).
>> No
>> > >         change in default qemu for 4.2.
>> >
>> > Anthony's PCI passthrough patches?
>>
>> Right. And Anthony's save/restore patches as well.
>
> Since these are dependent on external factors (qemu upstream) are we
> willing to block our own release for them?
>
> Given that upstream qemu won't be the default in this release I think
> the answer is "no", although obviously they are nice to haves.
>
> Ian.
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 16 Jan 2012 14:30:54 +0000
> From: Ian Jackson <Ian.Jackson@eu.citrix.com>
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
> 	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell
> 	<Ian.Campbell@citrix.com>,	Stefano Stabellini
> 	<Stefano.Stabellini@eu.citrix.com>
> Subject: Re: [Xen-devel] [xen-unstable bisection] complete
> 	test-i386-i386-xl
> Message-ID: <20244.13470.956567.815603@mariner.uk.xensource.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Paul Durrant writes ("RE: [Xen-devel] [xen-unstable bisection] complete
> test-i386-i386-xl"):
>> > -----Original Message-----
>> > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> ...
>> > So as you were the author of the original patch, can you please try to
>> > reproduce the problem and fix it ?
>> >
>>
>> Already on it.
>
> Great, thanks.  If you need any help, or to borrow the machine from my
> test pool, or something, just let me know.
>
> Ian.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 16 Jan 2012 14:39:07 +0000 (GMT)
> From: David TECHER <davidtecher@yahoo.fr>
> To: Ian Campbell <Ian.Campbell@citrix.com>, Pasi K?rkk?inen
> 	<pasik@iki.fi>
> Cc: xen-devel <xen-devel@lists.xensource.com>,	"Keir \(Xen.org\)"
> 	<keir@xen.org>,	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
> 	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson
> 	<Ian.Jackson@eu.citrix.com>,	Jan Beulich <JBeulich@suse.com>
> Subject: [Xen-devel] Re :  RFC: Still TODO for 4.2?
> Message-ID:
> 	<1326724747.73001.YahooMailNeo@web29802.mail.ird.yahoo.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I told a couple weeks ago that I will try to submit the patches.
>
> Sorry I am not submitting patches. I was/am very busy these last weeks.
>
>
> I will try to submit patches for VGA passthrough this week-end.
>
> Kind regards.
>
> David.
>
>
>
> ________________________________
>  De?: Ian Campbell <Ian.Campbell@citrix.com>
> ??: Pasi K?rkk?inen <pasik@iki.fi>
> Cc?: xen-devel <xen-devel@lists.xensource.com>; Keir (Xen.org)
> <keir@xen.org>; Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>; Ian
> Jackson <Ian.Jackson@eu.citrix.com>; Tim (Xen.org) <tim@xen.org>; Jan
> Beulich <JBeulich@suse.com>
> Envoy? le : Lundi 16 Janvier 2012 14h28
> Objet?: Re: [Xen-devel] RFC: Still TODO for 4.2?
>
> On Wed, 2012-01-04 at 17:25 +0000, Pasi K?rkk?inen wrote:
>>
>> - Also there's a bunch of VGA passthru related patches,
>> that I once volunteered to collect/rebase/cleanup/repost myself,
>> but I still haven't had time for that :(
>
> I'm not going to include this in the list unless someone steps up and
> starts submitting patches.
>
> Ian.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.xensource.com/archives/html/xen-devel/attachments/20120116/a7a09a9a/attachment.html>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 16 Jan 2012 14:40:07 +0000
> From: Jean Guyader <jean.guyader@eu.citrix.com>
> To: <xen-devel@lists.xensource.com>
> Cc: Ian.Jackson@eu.citrix.com, allen.m.kay@intel.com,	Jean Guyader
> 	<jean.guyader@eu.citrix.com>
> Subject: [Xen-devel] [PATCH] [passthrough] Change init for pt_pci_host
> 	return value.
> Message-ID:
> 	<1326724807-25718-1-git-send-email-jean.guyader@eu.citrix.com>
> Content-Type: text/plain; charset="utf-8"; Format="fixed"
>
>
> With an init of -1 all the return value smaller than a double word
> will be prefixed with "f"s.
>
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
>  hw/pass-through.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: 0001-passthrough-Change-init-for-pt_pci_host-return-value.patch
> Type: text/x-patch
> Size: 396 bytes
> Desc: not available
> URL:
> <http://lists.xensource.com/archives/html/xen-devel/attachments/20120116/ec356780/attachment.bin>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 16 Jan 2012 14:40:27 +0000
> From: Jean Guyader <jean.guyader@eu.citrix.com>
> To: xen-devel@lists.xensource.com
> Cc: Ian.Jackson@eu.citrix.com, allen.m.kay@intel.com,	Jean Guyader
> 	<jean.guyader@eu.citrix.com>
> Subject: [Xen-devel] [PATCH] intel gpu passthrough: Expose vendor
> 	specific	pci cap on host bridge.
> Message-ID:
> 	<1326724827-25759-1-git-send-email-jean.guyader@eu.citrix.com>
> Content-Type: text/plain; charset="utf-8"; Format="fixed"
>
>
> Some versions of the Windows Intel GPU driver expect the vendor
> PCI capability to be there on the host bridge config space when
> passing through a Intel GPU.
>
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
>  hw/pt-graphics.c |   51
> ++++++++++++++++++++++++++++++++++++++++++++++-----
>  1 files changed, 46 insertions(+), 5 deletions(-)
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: 0001-intel-gpu-passthrough-Expose-vendor-specific-pci-cap.patch
> Type: text/x-patch
> Size: 2551 bytes
> Desc: not available
> URL:
> <http://lists.xensource.com/archives/html/xen-devel/attachments/20120116/fa8c7dac/attachment.bin>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 16 Jan 2012 22:43:54 +0800
> From: Nai Xia <nai.xia@gmail.com>
> To: Grzegorz Milos <Grzegorz.Milos@citrix.com>
> Cc: xen-devel@lists.xensource.com
> Subject: [Xen-devel] Is this a racing bug in page_make_sharable()?
> Message-ID:
> 	<CAPQyPG5tW+Y2Snyf8qF8nn5pYcwrz=craTeedv_nAP8r8c9Q-A@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Grzegorz,
>
> As I understand, the purpose of the code in page_make_sharable()
> checking the ref count is to ensure that nobody unexpected is working
> on the page, and so we can migrate it to dom_cow, right?
>
> ====
>     /* Check if the ref count is 2. The first from PGT_allocated, and
>      * the second from get_page_and_type at the top of this function */
>     if(page->count_info != (PGC_allocated | (2 + expected_refcnt)))
>     {
>         /* Return type count back to zero */
>         put_page_and_type(page);
>         spin_unlock(&d->page_alloc_lock);
>         return -E2BIG;
>     }
> ====
>
> However, it seems to me that this ref check and the following page
> migration is not atomic( although the operations for type_info ref
> check seems good) i.e. it's possible that it passed this ref
> check but just before it goes to dom_cow, someone else gets this page?
> As far as I know, in Linux kernel's similar scenarios, they do
> ref-freezing
> tricks.
>
> And if we don't need to worry about this racing case, then what is
> this check trying to ensure?
>
>
> Thanks,
> Nai
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 83, Issue 233
> ******************************************
>

Re: RFC: Still TODO for 4.2?

[Stefano Stabellini]

On Mon, 16 Jan 2012, Jan Beulich wrote:
> >>> On 16.01.12 at 14:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
> >> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> 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?
> 
> I didn't see updated upstream qemu patches since this was discussed
> on irc - Anthony, do you have a rough time line?
 
We had long discussions on qemu-devel and on #qemu, I think we have a
plan now and I am currently prototyping a different approach to solve
the issue. The new approach requires libxl support, so I would still
like to put upstream qemu save/restore in the roadmap, at least for the
libxl side.

Re: RFC: Still TODO for 4.2?

[Jan Beulich]

>>> On 16.01.12 at 14:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
>> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> 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?

I didn't see updated upstream qemu patches since this was discussed
on irc - Anthony, do you have a rough time line?

Jan

Re: RFC: Still TODO for 4.2?

[Ian Campbell]

On Wed, 2012-01-04 at 16:51 +0000, Stefano Stabellini wrote:
> On Wed, 4 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> > >       * Integrate qemu+seabios upstream into the build (Stefano has
> > >         posted patches, I guess they need refreshing and reposting). No
> > >         change in default qemu for 4.2.
> > 
> > Anthony's PCI passthrough patches?
> 
> Right. And Anthony's save/restore patches as well.

Since these are dependent on external factors (qemu upstream) are we
willing to block our own release for them?

Given that upstream qemu won't be the default in this release I think
the answer is "no", although obviously they are nice to haves.

Ian.

Re: RFC: Still TODO for 4.2?

[Ian Campbell]

On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> 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?

Ian.

Re: RFC: Still TODO for 4.2?

[Ian Campbell]

On Wed, 2012-01-04 at 17:25 +0000, Pasi Kärkkäinen wrote:
> 
> - Also there's a bunch of VGA passthru related patches,
> that I once volunteered to collect/rebase/cleanup/repost myself,
> but I still haven't had time for that :( 

I'm not going to include this in the list unless someone steps up and
starts submitting patches.

Ian.



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

Re: RFC: Still TODO for 4.2?

[George Dunlap]

On Wed, Jan 4, 2012 at 4:29 PM, Ian Campbell <Ian.Campbell@citrix.com> 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?
>
> tools:
>
>      * libxl stable API -- we would like 4.2 to define a stable API
>        which downstream's can start to rely on not changing. Aspects of
>        this are:
>              * event handling (IanJ working on this)
>              * drop libxl_device_model_info (move bits to build_info or
>                elsewhere as appropriate) (IanC working on this, patches
>                shortly)
>              * add libxl_defbool and generally try and arrange that
>                memset(foo,0,...) requests the defaults (IanC working on
>                this, patches shortly)
>              * The topologyinfo datastructure should be a list of
>                tuples, not a tuple of lists. (nobody currently looking
>                at this, not 100% sure this makes sense, could possibly
>                defer and change after 4.2 in a compatible way)
>              * Block script support -- can be done post 4.2?
>      * Hotplug script stuff -- internal to libxl (I think, therefore I
>        didn't put this under stable API above) but still good to have
>        for 4.2? Roger Pau Monet was looking at this but its looking
>        like a big can-o-worms...
>      * Integrate qemu+seabios upstream into the build (Stefano has
>        posted patches, I guess they need refreshing and reposting). No
>        change in default qemu for 4.2.
>      * More formally deprecate xm/xend. Manpage patches already in
>        tree. Needs release noting and communication around -rc1 to
>        remind people to test xl.
>
> Has anybody got anything else? I'm sure I've missed stuff. Are there any
> must haves e.g. in the paging/sharing spaces?

Seems like making sure xl has feature parity with xend wrt driver
domains would be something good to make sure we have, if we're going
to be deprecating xend.

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

Re: RFC: Still TODO for 4.2?

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] RFC: Still TODO for 4.2?"):
> I'd argue that the json output should be the default with sxp requiring
> a special option, even though that break backwards compat with xm. I
> have a hard time believing that the sexp printed by xl is close enough
> to the xm one that people haven't already been hacking around it in
> their parsers anyway...

Yes.  Now that we have a global xl configuration file, we could put an
option in there to revert to the weird sexps.

Ian.

Re: RFC: Still TODO for 4.2?

[Wei Huang]

On 01/06/2012 09:37 AM, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 04, 2012 at 01:57:28PM -0600, Wei Huang wrote:
>> On 01/04/2012 01:43 PM, Pasi K?rkk?inen wrote:
>>> On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:
>>>>>> Has anybody got anything else? I'm sure I've missed stuff. Are there any
>>>>>> must haves e.g. in the paging/sharing spaces?
>>>>>>
>>>>> - What's the status of Nested Hardware Virtualization?
>>>>> I remember some email saying Intel vmx-on-vmx has some performance
>>>>> issues,
>>>>> and amd svm-on-svm works better..
>>>>>
>>>>>
>>>>> - Also there's a bunch of VGA passthru related patches,
>>>>> that I once volunteered to collect/rebase/cleanup/repost myself,
>>>>> but I still haven't had time for that :(
>>>> Since there were quite a lot of interest on this subject, should we
>>>> document it in a separate wiki for working combinations (like
>>>> hypervisor, dom0, gfx card, driver version, tricks, etc)?
>>>>
>>> I actually once started writing down that kind of stuff:
>>> http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html
>>>
>>> Feel free to contribute :)
>>>
>>> There's also:
>>> http://wiki.xen.org/xenwiki/XenVGAPassthrough
>> Thanks for sharing. I will contribute my findings as needed. BTW, do you
>> need my VBIOS loading patches (sent long time ago) for AMD GPU? It is a
> Yes! Thought I haven't figured out yet how to extract the AMD GPU BIOS
> from the card. I've been able to pass in a Radeon 4870 to an Win 7 HVM
> guest and it works nicely.. the first time. After I shut down the guest
> it just never works again :-(

This is a known issue which should be addressed for 4.2. I remember 
several persons reported this problem.

>
>> dilemma for several reasons:  it doesn't always work; sometimes it can
>> screw up main display while passthru 2nd GPUs. Plus the recent Catalyst
>> driver seems very stable even without these patches. But Wei Wang told
>> me that he needs them for some of his cards.
>>> -- Pasi
>>>
>>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel

Re: RFC: Still TODO for 4.2?

[Konrad Rzeszutek Wilk]

On Wed, Jan 04, 2012 at 01:57:28PM -0600, Wei Huang wrote:
> On 01/04/2012 01:43 PM, Pasi K?rkk?inen wrote:
> >On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:
> >>>>Has anybody got anything else? I'm sure I've missed stuff. Are there any
> >>>>must haves e.g. in the paging/sharing spaces?
> >>>>
> >>>- What's the status of Nested Hardware Virtualization?
> >>>I remember some email saying Intel vmx-on-vmx has some performance 
> >>>issues,
> >>>and amd svm-on-svm works better..
> >>>
> >>>
> >>>- Also there's a bunch of VGA passthru related patches,
> >>>that I once volunteered to collect/rebase/cleanup/repost myself,
> >>>but I still haven't had time for that :(
> >>Since there were quite a lot of interest on this subject, should we
> >>document it in a separate wiki for working combinations (like
> >>hypervisor, dom0, gfx card, driver version, tricks, etc)?
> >>
> >I actually once started writing down that kind of stuff:
> >http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html
> >
> >Feel free to contribute :)
> >
> >There's also:
> >http://wiki.xen.org/xenwiki/XenVGAPassthrough
> Thanks for sharing. I will contribute my findings as needed. BTW, do you 
> need my VBIOS loading patches (sent long time ago) for AMD GPU? It is a 

Yes! Thought I haven't figured out yet how to extract the AMD GPU BIOS
from the card. I've been able to pass in a Radeon 4870 to an Win 7 HVM
guest and it works nicely.. the first time. After I shut down the guest
it just never works again :-(

> dilemma for several reasons:  it doesn't always work; sometimes it can 
> screw up main display while passthru 2nd GPUs. Plus the recent Catalyst 
> driver seems very stable even without these patches. But Wei Wang told 
> me that he needs them for some of his cards.
> >
> >-- Pasi
> >
> >
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: RFC: Still TODO for 4.2?

[Ian Campbell]

On Thu, 2012-01-05 at 17:49 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] RFC: Still TODO for 4.2?"):
> > 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?
> > 
> > tools:
> > 
> >       * libxl stable API -- we would like 4.2 to define a stable API
> >         which downstream's can start to rely on not changing. Aspects of
> >         this are:
> 
> Relatedly, xl should have a json-based querier intended for users to
> not have to use the weird handwritten sexp printfs.

You mean for the "create -d" output? I agree and I've got such a patch
somewhere that I could polish off (and will).

I'd argue that the json output should be the default with sxp requiring
a special option, even though that break backwards compat with xm. I
have a hard time believing that the sexp printed by xl is close enough
to the xm one that people haven't already been hacking around it in
their parsers anyway...

Ian.

Re: RFC: Still TODO for 4.2?

[Ian Jackson]

Ian Campbell writes ("[Xen-devel] RFC: Still TODO for 4.2?"):
> 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?
> 
> tools:
> 
>       * libxl stable API -- we would like 4.2 to define a stable API
>         which downstream's can start to rely on not changing. Aspects of
>         this are:

Relatedly, xl should have a json-based querier intended for users to
not have to use the weird handwritten sexp printfs.

Ian.

Re: RFC: Still TODO for 4.2?

[Ian Campbell]

On Thu, 2012-01-05 at 13:41 +0000, David TECHER wrote:
> Ian
> 
> 
> I will try to submit the patch tonight when I am at home (I am in
> France - C.E.T) else you can download patches at
> http://www.davidgis.fr/download/xen-4.2_rev24232_gfx-passthrough-patchs.tar.bz2

Thanks, I'm not actually interested in this functionality myself -- I
just wanted to encourage their submission upstream since others seem to
want them.

> For your information and as it is writtten in my article, I am not the
> author of the patches, just a simple maintainer.

Then there is one additional wrinkle over and above what is described in
the SubmittingXenPatches wiki page, you should include a "Signed-off-by"
from the original author above your own.

Hopefully they included one when they originally posted the patch, in
which case you can just pass it on. If they did not then please CC them
on the posting and ask them to supply it (don't just make it up
yourself).

Hopefully the original authorship of all the patches is clear, if not
please note this in your changelog and we'll see if we can track them
down etc.

> However tt is worth having a try for submitting tonight

Please.

Thanks,
Ian.

> 
> 
> 
> Thanks.
> 
> 
> David.
> 
> 
> 
> ______________________________________________________________________
> De : Ian Campbell <Ian.Campbell@citrix.com>
> À : David TECHER <davidtecher@yahoo.fr> 
> Cc : xen-devel <xen-devel@lists.xensource.com>; Keir (Xen.org)
> <keir@xen.org>; Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>;
> Tim (Xen.org) <tim@xen.org>; Wei Huang <wei.huang2@amd.com>; Ian
> Jackson <Ian.Jackson@eu.citrix.com>; Jan Beulich <JBeulich@suse.com> 
> Envoyé le : Jeudi 5 Janvier 2012 14h25
> Objet : Re: [Xen-devel] RFC: Still TODO for 4.2?
> 
> On Thu, 2012-01-05 at 13:19 +0000, David TECHER wrote:
> > Pasi
> > 
> > 
> > I tryied to maintain the patches for Xen 4.2  since a few month.
> > 
> > 
> > Please have a look
> >
> http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through
> 
> Please can you post these patches, against the tip of xen-unstable,
> with
> a changelog etc as described in
> http://wiki.xen.org/wiki/SubmittingXenPatches to xen-devel.
> 
> Then we can look at accepting them in to the tree and you can stop
> needing to maintain them like this. Or is there some reason these
> can't
> be submitted?
> 
> Ian.
> 
> > 
> > 
> > Once a week, I try to test the patches.
> > 
> > 
> > Let me know if I can contribute.
> > 
> > 
> > David
> > 
> > 
> >
> ______________________________________________________________________
> > De : Pasi Kärkkäinen <pasik@iki.fi>
> > À : Wei Huang <wei.huang2@amd.com> 
> > Cc : xen-devel <xen-devel@lists.xensource.com>; Keir Fraser
> > <keir@xen.org>; Ian Campbell <Ian.Campbell@citrix.com>; Tim Deegan
> > <tim@xen.org>; Ian Jackson <Ian.Jackson@eu.citrix.com>; Stefano
> > Stabellini <stefano.stabellini@citrix.com>; Jan Beulich
> > <JBeulich@suse.com> 
> > Envoyé le : Mercredi 4 Janvier 2012 20h43
> > Objet : Re: [Xen-devel] RFC: Still TODO for 4.2?
> > 
> > On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:
> > >>>
> > >>> Has anybody got anything else? I'm sure I've missed stuff. Are
> > there any
> > >>> must haves e.g. in the paging/sharing spaces?
> > >>>
> > >> - What's the status of Nested Hardware Virtualization?
> > >> I remember some email saying Intel vmx-on-vmx has some
> performance
> > issues,
> > >> and amd svm-on-svm works better..
> > >>
> > >>
> > >> - Also there's a bunch of VGA passthru related patches,
> > >> that I once volunteered to collect/rebase/cleanup/repost myself,
> > >> but I still haven't had time for that :(
> > > Since there were quite a lot of interest on this subject, should
> > we  
> > > document it in a separate wiki for working combinations (like  
> > > hypervisor, dom0, gfx card, driver version, tricks, etc)?
> > >
> > 
> > I actually once started writing down that kind of stuff:
> > http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html
> > 
> > Feel free to contribute :)
> > 
> > There's also:
> > http://wiki.xen.org/xenwiki/XenVGAPassthrough
> > 
> > 
> > -- Pasi
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> > 
> > 
> > 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
> 



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

Re: RFC: Still TODO for 4.2?

[Ian Campbell]

On Thu, 2012-01-05 at 13:19 +0000, David TECHER wrote:
> Pasi
> 
> 
> I tryied to maintain the patches for Xen 4.2  since a few month.
> 
> 
> Please have a look
> http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through

Please can you post these patches, against the tip of xen-unstable, with
a changelog etc as described in
http://wiki.xen.org/wiki/SubmittingXenPatches to xen-devel.

Then we can look at accepting them in to the tree and you can stop
needing to maintain them like this. Or is there some reason these can't
be submitted?

Ian.

> 
> 
> Once a week, I try to test the patches.
> 
> 
> Let me know if I can contribute.
> 
> 
> David
> 
> 
> ______________________________________________________________________
> De : Pasi Kärkkäinen <pasik@iki.fi>
> À : Wei Huang <wei.huang2@amd.com> 
> Cc : xen-devel <xen-devel@lists.xensource.com>; Keir Fraser
> <keir@xen.org>; Ian Campbell <Ian.Campbell@citrix.com>; Tim Deegan
> <tim@xen.org>; Ian Jackson <Ian.Jackson@eu.citrix.com>; Stefano
> Stabellini <stefano.stabellini@citrix.com>; Jan Beulich
> <JBeulich@suse.com> 
> Envoyé le : Mercredi 4 Janvier 2012 20h43
> Objet : Re: [Xen-devel] RFC: Still TODO for 4.2?
> 
> On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:
> >>>
> >>> Has anybody got anything else? I'm sure I've missed stuff. Are
> there any
> >>> must haves e.g. in the paging/sharing spaces?
> >>>
> >> - What's the status of Nested Hardware Virtualization?
> >> I remember some email saying Intel vmx-on-vmx has some performance
> issues,
> >> and amd svm-on-svm works better..
> >>
> >>
> >> - Also there's a bunch of VGA passthru related patches,
> >> that I once volunteered to collect/rebase/cleanup/repost myself,
> >> but I still haven't had time for that :(
> > Since there were quite a lot of interest on this subject, should
> we  
> > document it in a separate wiki for working combinations (like  
> > hypervisor, dom0, gfx card, driver version, tricks, etc)?
> >
> 
> I actually once started writing down that kind of stuff:
> http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html
> 
> Feel free to contribute :)
> 
> There's also:
> http://wiki.xen.org/xenwiki/XenVGAPassthrough
> 
> 
> -- Pasi
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
> 



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

Re: RFC: Still TODO for 4.2?

[Ian Campbell]

On Wed, 2012-01-04 at 18:20 +0000, Tim Deegan wrote:
> At 19:25 +0200 on 04 Jan (1325705119), Pasi K?rkk?inen wrote:
> > On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell 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?
> 
> I would like to get the interface changes for sharing/paging/mem-events
> done and dusted so that 4.2 is a stable API that we hold to.
> 
> It would be nice to get the implementation solid too (i.e., using wait
> queues) but that can happen later if it's the only thing holding up a
> release.
> 
> > - What's the status of Nested Hardware Virtualization? 
> > I remember some email saying Intel vmx-on-vmx has some performance issues,
> > and amd svm-on-svm works better..

That's the impression that I've gotten too.

> The basic feature is in for AMD and Intel, but AIUI it's not getting a
> lot of use and it's not in the xen.org automated testing.  The AMD code
> has nested-paging support too, which is a requirement for decent
> performance. 
> 
> We could call it 'experimental' for 4.2?

IMHO we shouldn't hold up the release for it so either it is working by
the time the release happens or it is experimental. (I guess we should
consider svm-on-svm and vmx-on-vmx separately for these purposes).

Ian.

Re: RFC: Still TODO for 4.2?

[Pasi Kärkkäinen]

On Wed, Jan 04, 2012 at 01:57:28PM -0600, Wei Huang wrote:
> On 01/04/2012 01:43 PM, Pasi Kärkkäinen wrote:
>> On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:
>>>>> Has anybody got anything else? I'm sure I've missed stuff. Are there any
>>>>> must haves e.g. in the paging/sharing spaces?
>>>>>
>>>> - What's the status of Nested Hardware Virtualization?
>>>> I remember some email saying Intel vmx-on-vmx has some performance issues,
>>>> and amd svm-on-svm works better..
>>>>
>>>>
>>>> - Also there's a bunch of VGA passthru related patches,
>>>> that I once volunteered to collect/rebase/cleanup/repost myself,
>>>> but I still haven't had time for that :(
>>> Since there were quite a lot of interest on this subject, should we
>>> document it in a separate wiki for working combinations (like
>>> hypervisor, dom0, gfx card, driver version, tricks, etc)?
>>>
>> I actually once started writing down that kind of stuff:
>> http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html
>>
>> Feel free to contribute :)
>>
>> There's also:
>> http://wiki.xen.org/xenwiki/XenVGAPassthrough
> Thanks for sharing. I will contribute my findings as needed. BTW, do you  
> need my VBIOS loading patches (sent long time ago) for AMD GPU? It is a  
> dilemma for several reasons:  it doesn't always work; sometimes it can  
> screw up main display while passthru 2nd GPUs. Plus the recent Catalyst  
> driver seems very stable even without these patches. But Wei Wang told  
> me that he needs them for some of his cards.
>

Yes, please send the patch!

-- Pasi

Re: RFC: Still TODO for 4.2?

[Wei Huang]

On 01/04/2012 01:43 PM, Pasi Kärkkäinen wrote:
> On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:
>>>> Has anybody got anything else? I'm sure I've missed stuff. Are there any
>>>> must haves e.g. in the paging/sharing spaces?
>>>>
>>> - What's the status of Nested Hardware Virtualization?
>>> I remember some email saying Intel vmx-on-vmx has some performance issues,
>>> and amd svm-on-svm works better..
>>>
>>>
>>> - Also there's a bunch of VGA passthru related patches,
>>> that I once volunteered to collect/rebase/cleanup/repost myself,
>>> but I still haven't had time for that :(
>> Since there were quite a lot of interest on this subject, should we
>> document it in a separate wiki for working combinations (like
>> hypervisor, dom0, gfx card, driver version, tricks, etc)?
>>
> I actually once started writing down that kind of stuff:
> http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html
>
> Feel free to contribute :)
>
> There's also:
> http://wiki.xen.org/xenwiki/XenVGAPassthrough
Thanks for sharing. I will contribute my findings as needed. BTW, do you 
need my VBIOS loading patches (sent long time ago) for AMD GPU? It is a 
dilemma for several reasons:  it doesn't always work; sometimes it can 
screw up main display while passthru 2nd GPUs. Plus the recent Catalyst 
driver seems very stable even without these patches. But Wei Wang told 
me that he needs them for some of his cards.
>
> -- Pasi
>
>

Re: RFC: Still TODO for 4.2?

[Pasi Kärkkäinen]

On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:
>>>
>>> Has anybody got anything else? I'm sure I've missed stuff. Are there any
>>> must haves e.g. in the paging/sharing spaces?
>>>
>> - What's the status of Nested Hardware Virtualization?
>> I remember some email saying Intel vmx-on-vmx has some performance issues,
>> and amd svm-on-svm works better..
>>
>>
>> - Also there's a bunch of VGA passthru related patches,
>> that I once volunteered to collect/rebase/cleanup/repost myself,
>> but I still haven't had time for that :(
> Since there were quite a lot of interest on this subject, should we  
> document it in a separate wiki for working combinations (like  
> hypervisor, dom0, gfx card, driver version, tricks, etc)?
>

I actually once started writing down that kind of stuff:
http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html

Feel free to contribute :)

There's also:
http://wiki.xen.org/xenwiki/XenVGAPassthrough


-- Pasi

Re: RFC: Still TODO for 4.2?

[Wei Huang]

On 01/04/2012 11:25 AM, Pasi Kärkkäinen wrote:
> On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell 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?
>>
>> tools:
>>
>>        * libxl stable API -- we would like 4.2 to define a stable API
>>          which downstream's can start to rely on not changing. Aspects of
>>          this are:
>>                * event handling (IanJ working on this)
>>                * drop libxl_device_model_info (move bits to build_info or
>>                  elsewhere as appropriate) (IanC working on this, patches
>>                  shortly)
>>                * add libxl_defbool and generally try and arrange that
>>                  memset(foo,0,...) requests the defaults (IanC working on
>>                  this, patches shortly)
>>                * The topologyinfo datastructure should be a list of
>>                  tuples, not a tuple of lists. (nobody currently looking
>>                  at this, not 100% sure this makes sense, could possibly
>>                  defer and change after 4.2 in a compatible way)
>>                * Block script support -- can be done post 4.2?
>>        * Hotplug script stuff -- internal to libxl (I think, therefore I
>>          didn't put this under stable API above) but still good to have
>>          for 4.2? Roger Pau Monet was looking at this but its looking
>>          like a big can-o-worms...
>>        * Integrate qemu+seabios upstream into the build (Stefano has
>>          posted patches, I guess they need refreshing and reposting). No
>>          change in default qemu for 4.2.
>>        * More formally deprecate xm/xend. Manpage patches already in
>>          tree. Needs release noting and communication around -rc1 to
>>          remind people to test xl.
>>
>> Has anybody got anything else? I'm sure I've missed stuff. Are there any
>> must haves e.g. in the paging/sharing spaces?
>>
> - What's the status of Nested Hardware Virtualization?
> I remember some email saying Intel vmx-on-vmx has some performance issues,
> and amd svm-on-svm works better..
>
>
> - Also there's a bunch of VGA passthru related patches,
> that I once volunteered to collect/rebase/cleanup/repost myself,
> but I still haven't had time for that :(
Since there were quite a lot of interest on this subject, should we 
document it in a separate wiki for working combinations (like 
hypervisor, dom0, gfx card, driver version, tricks, etc)?
>
> -- Pasi
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

Re: RFC: Still TODO for 4.2?

[Tim Deegan]

At 19:25 +0200 on 04 Jan (1325705119), Pasi K?rkk?inen wrote:
> On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell 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?

I would like to get the interface changes for sharing/paging/mem-events
done and dusted so that 4.2 is a stable API that we hold to.

It would be nice to get the implementation solid too (i.e., using wait
queues) but that can happen later if it's the only thing holding up a
release.

> - What's the status of Nested Hardware Virtualization? 
> I remember some email saying Intel vmx-on-vmx has some performance issues,
> and amd svm-on-svm works better..

The basic feature is in for AMD and Intel, but AIUI it's not getting a
lot of use and it's not in the xen.org automated testing.  The AMD code
has nested-paging support too, which is a requirement for decent
performance. 

We could call it 'experimental' for 4.2?

Cheers,

Tim.

Re: RFC: Still TODO for 4.2?

[Roger Pau Monné]

2012/1/4 Ian Campbell <Ian.Campbell@citrix.com>:
> 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?
>
> tools:
>
>      * libxl stable API -- we would like 4.2 to define a stable API
>        which downstream's can start to rely on not changing. Aspects of
>        this are:
>              * event handling (IanJ working on this)
>              * drop libxl_device_model_info (move bits to build_info or
>                elsewhere as appropriate) (IanC working on this, patches
>                shortly)
>              * add libxl_defbool and generally try and arrange that
>                memset(foo,0,...) requests the defaults (IanC working on
>                this, patches shortly)
>              * The topologyinfo datastructure should be a list of
>                tuples, not a tuple of lists. (nobody currently looking
>                at this, not 100% sure this makes sense, could possibly
>                defer and change after 4.2 in a compatible way)
>              * Block script support -- can be done post 4.2?
>      * Hotplug script stuff -- internal to libxl (I think, therefore I
>        didn't put this under stable API above) but still good to have
>        for 4.2? Roger Pau Monet was looking at this but its looking
>        like a big can-o-worms...

The hotplug implementation I've sent can be improved with asynchronous
events once IanJ patches are in. Also it might be good to do some
cleaning of the Linux hotplug scripts, right now they are a style
mess, apart from the fact that they take different parameters
depending on the script being called, which I think could be avoided.

I don't know much about driver domains, but from what I've read they
should be running something like NetBSD xenbackend and listen for
xenstore events. Most of the functions that I've written on my hotplug
series can be used to create a little daemon, that's not the problem,
the problem is what can we use to synchronize hotplug script calling
and libxl (what comes to mind is using a dedicated xenstore variable
for each device, but someone might have a better idea).

>      * Integrate qemu+seabios upstream into the build (Stefano has
>        posted patches, I guess they need refreshing and reposting). No
>        change in default qemu for 4.2.
>      * More formally deprecate xm/xend. Manpage patches already in
>        tree. Needs release noting and communication around -rc1 to
>        remind people to test xl.
>
> Has anybody got anything else? I'm sure I've missed stuff. Are there any
> must haves e.g. in the paging/sharing spaces?

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

Re: RFC: Still TODO for 4.2?

[George Dunlap]

On Wed, Jan 4, 2012 at 12:25 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell 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?

It would be good to have domctls / sysctls set up to modify scheduler
parameters, like the credit1 timeslice (and schedule rate, if that
ever makes it in).

 -George

>>
>> tools:
>>
>>       * libxl stable API -- we would like 4.2 to define a stable API
>>         which downstream's can start to rely on not changing. Aspects of
>>         this are:
>>               * event handling (IanJ working on this)
>>               * drop libxl_device_model_info (move bits to build_info or
>>                 elsewhere as appropriate) (IanC working on this, patches
>>                 shortly)
>>               * add libxl_defbool and generally try and arrange that
>>                 memset(foo,0,...) requests the defaults (IanC working on
>>                 this, patches shortly)
>>               * The topologyinfo datastructure should be a list of
>>                 tuples, not a tuple of lists. (nobody currently looking
>>                 at this, not 100% sure this makes sense, could possibly
>>                 defer and change after 4.2 in a compatible way)
>>               * Block script support -- can be done post 4.2?
>>       * Hotplug script stuff -- internal to libxl (I think, therefore I
>>         didn't put this under stable API above) but still good to have
>>         for 4.2? Roger Pau Monet was looking at this but its looking
>>         like a big can-o-worms...
>>       * Integrate qemu+seabios upstream into the build (Stefano has
>>         posted patches, I guess they need refreshing and reposting). No
>>         change in default qemu for 4.2.
>>       * More formally deprecate xm/xend. Manpage patches already in
>>         tree. Needs release noting and communication around -rc1 to
>>         remind people to test xl.
>>
>> Has anybody got anything else? I'm sure I've missed stuff. Are there any
>> must haves e.g. in the paging/sharing spaces?
>>
>
> - What's the status of Nested Hardware Virtualization?
> I remember some email saying Intel vmx-on-vmx has some performance issues,
> and amd svm-on-svm works better..
>
>
> - Also there's a bunch of VGA passthru related patches,
> that I once volunteered to collect/rebase/cleanup/repost myself,
> but I still haven't had time for that :(
>
>
> -- Pasi
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: RFC: Still TODO for 4.2?

[Pasi Kärkkäinen]

On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell 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?
> 
> tools:
> 
>       * libxl stable API -- we would like 4.2 to define a stable API
>         which downstream's can start to rely on not changing. Aspects of
>         this are:
>               * event handling (IanJ working on this)
>               * drop libxl_device_model_info (move bits to build_info or
>                 elsewhere as appropriate) (IanC working on this, patches
>                 shortly)
>               * add libxl_defbool and generally try and arrange that
>                 memset(foo,0,...) requests the defaults (IanC working on
>                 this, patches shortly)
>               * The topologyinfo datastructure should be a list of
>                 tuples, not a tuple of lists. (nobody currently looking
>                 at this, not 100% sure this makes sense, could possibly
>                 defer and change after 4.2 in a compatible way)
>               * Block script support -- can be done post 4.2?
>       * Hotplug script stuff -- internal to libxl (I think, therefore I
>         didn't put this under stable API above) but still good to have
>         for 4.2? Roger Pau Monet was looking at this but its looking
>         like a big can-o-worms...
>       * Integrate qemu+seabios upstream into the build (Stefano has
>         posted patches, I guess they need refreshing and reposting). No
>         change in default qemu for 4.2.
>       * More formally deprecate xm/xend. Manpage patches already in
>         tree. Needs release noting and communication around -rc1 to
>         remind people to test xl.
> 
> Has anybody got anything else? I'm sure I've missed stuff. Are there any
> must haves e.g. in the paging/sharing spaces?
> 

- What's the status of Nested Hardware Virtualization? 
I remember some email saying Intel vmx-on-vmx has some performance issues,
and amd svm-on-svm works better..


- Also there's a bunch of VGA passthru related patches,
that I once volunteered to collect/rebase/cleanup/repost myself,
but I still haven't had time for that :(


-- Pasi

Re: RFC: Still TODO for 4.2?

[Jan Beulich]

>>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> 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.

Jan

Re: RFC: Still TODO for 4.2?

[Stefano Stabellini]

On Wed, 4 Jan 2012, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell 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?
> 
> Mark ARM as experimental? Docs on how to compile it, use it?
> 
> > 
> > tools:
> > 
> >       * libxl stable API -- we would like 4.2 to define a stable API
> >         which downstream's can start to rely on not changing. Aspects of
> >         this are:
> >               * event handling (IanJ working on this)
> >               * drop libxl_device_model_info (move bits to build_info or
> >                 elsewhere as appropriate) (IanC working on this, patches
> >                 shortly)
> >               * add libxl_defbool and generally try and arrange that
> >                 memset(foo,0,...) requests the defaults (IanC working on
> >                 this, patches shortly)
> >               * The topologyinfo datastructure should be a list of
> >                 tuples, not a tuple of lists. (nobody currently looking
> >                 at this, not 100% sure this makes sense, could possibly
> >                 defer and change after 4.2 in a compatible way)
> >               * Block script support -- can be done post 4.2?
> >       * Hotplug script stuff -- internal to libxl (I think, therefore I
> >         didn't put this under stable API above) but still good to have
> >         for 4.2? Roger Pau Monet was looking at this but its looking
> >         like a big can-o-worms...
> >       * Integrate qemu+seabios upstream into the build (Stefano has
> >         posted patches, I guess they need refreshing and reposting). No
> >         change in default qemu for 4.2.
> 
> Anthony's PCI passthrough patches?

Right. And Anthony's save/restore patches as well.

Re: RFC: Still TODO for 4.2?

[Konrad Rzeszutek Wilk]

On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell 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?

Mark ARM as experimental? Docs on how to compile it, use it?

> 
> tools:
> 
>       * libxl stable API -- we would like 4.2 to define a stable API
>         which downstream's can start to rely on not changing. Aspects of
>         this are:
>               * event handling (IanJ working on this)
>               * drop libxl_device_model_info (move bits to build_info or
>                 elsewhere as appropriate) (IanC working on this, patches
>                 shortly)
>               * add libxl_defbool and generally try and arrange that
>                 memset(foo,0,...) requests the defaults (IanC working on
>                 this, patches shortly)
>               * The topologyinfo datastructure should be a list of
>                 tuples, not a tuple of lists. (nobody currently looking
>                 at this, not 100% sure this makes sense, could possibly
>                 defer and change after 4.2 in a compatible way)
>               * Block script support -- can be done post 4.2?
>       * Hotplug script stuff -- internal to libxl (I think, therefore I
>         didn't put this under stable API above) but still good to have
>         for 4.2? Roger Pau Monet was looking at this but its looking
>         like a big can-o-worms...
>       * Integrate qemu+seabios upstream into the build (Stefano has
>         posted patches, I guess they need refreshing and reposting). No
>         change in default qemu for 4.2.

Anthony's PCI passthrough patches?

>       * More formally deprecate xm/xend. Manpage patches already in
>         tree. Needs release noting and communication around -rc1 to
>         remind people to test xl.

> 
> Has anybody got anything else? I'm sure I've missed stuff. Are there any
> must haves e.g. in the paging/sharing spaces?
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

RFC: Still TODO for 4.2?

[Ian Campbell]

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?

tools:

      * libxl stable API -- we would like 4.2 to define a stable API
        which downstream's can start to rely on not changing. Aspects of
        this are:
              * event handling (IanJ working on this)
              * drop libxl_device_model_info (move bits to build_info or
                elsewhere as appropriate) (IanC working on this, patches
                shortly)
              * add libxl_defbool and generally try and arrange that
                memset(foo,0,...) requests the defaults (IanC working on
                this, patches shortly)
              * The topologyinfo datastructure should be a list of
                tuples, not a tuple of lists. (nobody currently looking
                at this, not 100% sure this makes sense, could possibly
                defer and change after 4.2 in a compatible way)
              * Block script support -- can be done post 4.2?
      * Hotplug script stuff -- internal to libxl (I think, therefore I
        didn't put this under stable API above) but still good to have
        for 4.2? Roger Pau Monet was looking at this but its looking
        like a big can-o-worms...
      * Integrate qemu+seabios upstream into the build (Stefano has
        posted patches, I guess they need refreshing and reposting). No
        change in default qemu for 4.2.
      * More formally deprecate xm/xend. Manpage patches already in
        tree. Needs release noting and communication around -rc1 to
        remind people to test xl.

Has anybody got anything else? I'm sure I've missed stuff. Are there any
must haves e.g. in the paging/sharing spaces?

Ian.