Xen devel - Jul 2011 - Question on "xen-blkfront: handle Xen major numbers other than XENVBD"

This is /me trying to understand the background of

commit c80a420995e721099906607b07c09a24543b31d9
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Thu Dec 2 17:55:00 2010 +0000

    xen-blkfront: handle Xen major numbers other than XENVBD

My guess would be that it has its reason from running HVM guests. The issue I in
some way hear in complaints is, that running as PVM guest (at least) people seem
to have used for example "sda1" in the instance configuration and then
relied on
the device being called that way within the instance. Now it is suddenly called
"xvde1".
This is maybe a broken assumption in the first place, and not that hard to cope
with (its just surprising and maybe breaks some automation). I mainly want to
understand the reasoning, so I can explain it where I get asked.

Thanks,
Stefan

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

On Wed, 13 Jul 2011, Stefan Bader wrote:
> This is /me trying to understand the background of
> 
> commit c80a420995e721099906607b07c09a24543b31d9
> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Date:   Thu Dec 2 17:55:00 2010 +0000
> 
>     xen-blkfront: handle Xen major numbers other than XENVBD
> 
> My guess would be that it has its reason from running HVM guests. The issue
I in
> some way hear in complaints is, that running as PVM guest (at least) people
seem
> to have used for example "sda1" in the instance configuration and
then relied on
> the device being called that way within the instance. Now it is suddenly
called
> "xvde1".
> This is maybe a broken assumption in the first place, and not that hard to
cope
> with (its just surprising and maybe breaks some automation). I mainly want
to
> understand the reasoning, so I can explain it where I get asked.
The rationale behind this is that it wouldn''t be correct for
xen-blkfront to "steal" the major number of the scsi, sata or ide
subsystems.

Of course if a LABEL or UUID is specified everything should work as
expected without any changes.
We do print a warning at boot time to make sure users know of the naming
change:

		printk(KERN_INFO "Blkfront and the Xen platform PCI driver have "
					"been compiled for this kernel: unplug emulated disks.\n"
					"You might have to change the root device\n"
					"from /dev/hd[a-d] to /dev/xvd[a-d]\n"
					"in your root= kernel command line option\n");

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

On Wed, 2011-07-13 at 11:47 +0100, Stefano Stabellini
wrote:
> On Wed, 13 Jul 2011, Stefan Bader wrote:
> > This is /me trying to understand the background of
> > 
> > commit c80a420995e721099906607b07c09a24543b31d9
> > Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Date:   Thu Dec 2 17:55:00 2010 +0000
> > 
> >     xen-blkfront: handle Xen major numbers other than XENVBD
> > 
> > My guess would be that it has its reason from running HVM guests. The
issue I in
> > some way hear in complaints is, that running as PVM guest (at least)
people seem
> > to have used for example "sda1" in the instance
configuration and then relied on
> > the device being called that way within the instance. Now it is
suddenly called
> > "xvde1".
> > This is maybe a broken assumption in the first place, and not that
hard to cope
> > with (its just surprising and maybe breaks some automation). I mainly
want to
> > understand the reasoning, so I can explain it where I get asked.
> 
> The rationale behind this is that it wouldn''t be correct for
> xen-blkfront to "steal" the major number of the scsi, sata or ide
> subsystems.
It should be pointed out that the out of mainline "classic" PV Xen
patches do exactly that (although I at least have been discouraging the
use of this configuration for many years now). But it''s not something
we
felt would fly with upstream.

Ian.

> Of course if a LABEL or UUID is specified everything should work as
> expected without any changes.
> We do print a warning at boot time to make sure users know of the naming
> change:
> 
> 		printk(KERN_INFO "Blkfront and the Xen platform PCI driver have
"
> 					"been compiled for this kernel: unplug emulated disks.\n"
> 					"You might have to change the root device\n"
> 					"from /dev/hd[a-d] to /dev/xvd[a-d]\n"
> 					"in your root= kernel command line option\n");
> 
> _______________________________________________
> 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

On 13.07.2011 12:54, Ian Campbell wrote:
> On Wed, 2011-07-13 at 11:47 +0100, Stefano Stabellini wrote:
>> On Wed, 13 Jul 2011, Stefan Bader wrote:
>>> This is /me trying to understand the background of
>>>
>>> commit c80a420995e721099906607b07c09a24543b31d9
>>> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> Date:   Thu Dec 2 17:55:00 2010 +0000
>>>
>>>     xen-blkfront: handle Xen major numbers other than XENVBD
>>>
>>> My guess would be that it has its reason from running HVM guests.
The issue I in
>>> some way hear in complaints is, that running as PVM guest (at
least) people seem
>>> to have used for example "sda1" in the instance
configuration and then relied on
>>> the device being called that way within the instance. Now it is
suddenly called
>>> "xvde1".
>>> This is maybe a broken assumption in the first place, and not that
hard to cope
>>> with (its just surprising and maybe breaks some automation). I
mainly want to
>>> understand the reasoning, so I can explain it where I get asked.
>>
>> The rationale behind this is that it wouldn''t be correct for
>> xen-blkfront to "steal" the major number of the scsi, sata or
ide
>> subsystems.
> 
> It should be pointed out that the out of mainline "classic" PV
Xen
> patches do exactly that (although I at least have been discouraging the
> use of this configuration for many years now). But it''s not
something we
> felt would fly with upstream.
> 
> Ian.
> 
It is certainly desirable not to take the major numbers from other subsystems.
And it seems I was confused by switching between older and newer driver
versions. So saying "sda1" in the configuration _was_ already
converted into
"xvda1" and it was using the major of xvd. The surprising change was
in that
case that "sda1" now converts into "xvde1" (and funnily
"hda1" seems to become
"xvda", not "xvda1"). Though I think this is required to
have a sane mapping
when people mix hdx and sdx in the configuration.
> 
>> Of course if a LABEL or UUID is specified everything should work as
>> expected without any changes.
>> We do print a warning at boot time to make sure users know of the
naming
>> change:
>>
>> 		printk(KERN_INFO "Blkfront and the Xen platform PCI driver have
"
>> 					"been compiled for this kernel: unplug emulated
disks.\n"
>> 					"You might have to change the root device\n"
>> 					"from /dev/hd[a-d] to /dev/xvd[a-d]\n"
>> 					"in your root= kernel command line option\n");
>>
>> _______________________________________________
>> 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

On Wed, 13 Jul 2011, Stefan Bader wrote:
> On 13.07.2011 12:54, Ian Campbell wrote:
> > On Wed, 2011-07-13 at 11:47 +0100, Stefano Stabellini wrote:
> >> On Wed, 13 Jul 2011, Stefan Bader wrote:
> >>> This is /me trying to understand the background of
> >>>
> >>> commit c80a420995e721099906607b07c09a24543b31d9
> >>> Author: Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
> >>> Date:   Thu Dec 2 17:55:00 2010 +0000
> >>>
> >>>     xen-blkfront: handle Xen major numbers other than XENVBD
> >>>
> >>> My guess would be that it has its reason from running HVM
guests. The issue I in
> >>> some way hear in complaints is, that running as PVM guest (at
least) people seem
> >>> to have used for example "sda1" in the instance
configuration and then relied on
> >>> the device being called that way within the instance. Now it
is suddenly called
> >>> "xvde1".
> >>> This is maybe a broken assumption in the first place, and not
that hard to cope
> >>> with (its just surprising and maybe breaks some automation). I
mainly want to
> >>> understand the reasoning, so I can explain it where I get
asked.
> >>
> >> The rationale behind this is that it wouldn''t be correct
for
> >> xen-blkfront to "steal" the major number of the scsi,
sata or ide
> >> subsystems.
> > 
> > It should be pointed out that the out of mainline "classic"
PV Xen
> > patches do exactly that (although I at least have been discouraging
the
> > use of this configuration for many years now). But it''s not
something we
> > felt would fly with upstream.
> > 
> > Ian.
> > 
> 
> It is certainly desirable not to take the major numbers from other
subsystems.
> And it seems I was confused by switching between older and newer driver
> versions. So saying "sda1" in the configuration _was_ already
converted into
> "xvda1" and it was using the major of xvd. The surprising change
was in that
> case that "sda1" now converts into "xvde1" (and funnily
"hda1" seems to become
> "xvda", not "xvda1"). Though I think this is required
to have a sane mapping
> when people mix hdx and sdx in the configuration.
Actually this is a very tricky issue.

The problem is that if we translate "sda1" into "xvda1" then
what
happens if a users specifies both "sda1" and "hda1"? Of
course there is
going to be a conflict and the guest won''t boot.
In order to avoid the problem, xen-blkfront starts naming pv disks
corresponding to "sd" disks from xvde onwards and pv disks
corresponding
to "hd" disks from xvda onwards.

Initially we thought of naming pv disks corresponding to emulated disks
(both hd and sd) in a very unique way, so that they could never clash
with normal pv disks, something like xvdHDa1. However it was very
confusing to users so we decided to remove it and go for a simple
hda->xvda conversion. However the sda conversion remained 4 letters off
to avoid clashes with hda.
I guess we could remove that offset as well and make both hda and sda
correspond to xvda. Maybe easier to guess from the user POV but also
easier to create conflicts.

What do you think?

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

On 13.07.2011 15:20, Stefano Stabellini wrote:
> On Wed, 13 Jul 2011, Stefan Bader wrote:
>> On 13.07.2011 12:54, Ian Campbell wrote:
>>> On Wed, 2011-07-13 at 11:47 +0100, Stefano Stabellini wrote:
>>>> On Wed, 13 Jul 2011, Stefan Bader wrote:
>>>>> This is /me trying to understand the background of
>>>>>
>>>>> commit c80a420995e721099906607b07c09a24543b31d9
>>>>> Author: Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
>>>>> Date:   Thu Dec 2 17:55:00 2010 +0000
>>>>>
>>>>>     xen-blkfront: handle Xen major numbers other than
XENVBD
>>>>>
>>>>> My guess would be that it has its reason from running HVM
guests. The issue I in
>>>>> some way hear in complaints is, that running as PVM guest
(at least) people seem
>>>>> to have used for example "sda1" in the instance
configuration and then relied on
>>>>> the device being called that way within the instance. Now
it is suddenly called
>>>>> "xvde1".
>>>>> This is maybe a broken assumption in the first place, and
not that hard to cope
>>>>> with (its just surprising and maybe breaks some
automation). I mainly want to
>>>>> understand the reasoning, so I can explain it where I get
asked.
>>>>
>>>> The rationale behind this is that it wouldn''t be
correct for
>>>> xen-blkfront to "steal" the major number of the scsi,
sata or ide
>>>> subsystems.
>>>
>>> It should be pointed out that the out of mainline
"classic" PV Xen
>>> patches do exactly that (although I at least have been discouraging
the
>>> use of this configuration for many years now). But it''s
not something we
>>> felt would fly with upstream.
>>>
>>> Ian.
>>>
>>
>> It is certainly desirable not to take the major numbers from other
subsystems.
>> And it seems I was confused by switching between older and newer driver
>> versions. So saying "sda1" in the configuration _was_ already
converted into
>> "xvda1" and it was using the major of xvd. The surprising
change was in that
>> case that "sda1" now converts into "xvde1" (and
funnily "hda1" seems to become
>> "xvda", not "xvda1"). Though I think this is
required to have a sane mapping
>> when people mix hdx and sdx in the configuration.
> 
> Actually this is a very tricky issue.
> 
> The problem is that if we translate "sda1" into "xvda1"
then what
> happens if a users specifies both "sda1" and "hda1"? Of
course there is
> going to be a conflict and the guest won''t boot.
> In order to avoid the problem, xen-blkfront starts naming pv disks
> corresponding to "sd" disks from xvde onwards and pv disks
corresponding
> to "hd" disks from xvda onwards.
> 
> Initially we thought of naming pv disks corresponding to emulated disks
> (both hd and sd) in a very unique way, so that they could never clash
> with normal pv disks, something like xvdHDa1. However it was very
> confusing to users so we decided to remove it and go for a simple
> hda->xvda conversion. However the sda conversion remained 4 letters off
> to avoid clashes with hda.
> I guess we could remove that offset as well and make both hda and sda
> correspond to xvda. Maybe easier to guess from the user POV but also
> easier to create conflicts.
> 
> What do you think?
> 
Yeah, I understand the problem now that I thought of the possibility of having
both name types in the configuration. Though I could imagine that in reality
there will be no one having that done as it would have caused problems...
As you say, the only way to avoid any clashed is to have seperate namespaces.
But that again is unexpected now and people would complain.
The 4 letters offset probably still can get busted if someone decides to use hde
and sda. Detecting clashes at allocation time and then using another name for
the duplicate is likely to result in a random of the two to be the secondary.
My feeling would be that trying to map two namespaces into one will always be
confusing and/or failing to some degree. The reason to go back would only be
that this was broken before, so it can probably be expected that people have
avoided that mix.So it would be as it has been before. But I bet there are other
people that thought of it as a bug... Not an easy decision at all.
> _______________________________________________
> 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

On Wed, 13 Jul 2011, Stefan Bader wrote:
> Yeah, I understand the problem now that I thought of the possibility of
having
> both name types in the configuration. Though I could imagine that in
reality
> there will be no one having that done as it would have caused problems...
> As you say, the only way to avoid any clashed is to have seperate
namespaces.
> But that again is unexpected now and people would complain.
> The 4 letters offset probably still can get busted if someone decides to
use hde
> and sda. Detecting clashes at allocation time and then using another name
for
> the duplicate is likely to result in a random of the two to be the
secondary.
> My feeling would be that trying to map two namespaces into one will always
be
> confusing and/or failing to some degree. The reason to go back would only
be
> that this was broken before, so it can probably be expected that people
have
> avoided that mix.So it would be as it has been before. But I bet there are
other
> people that thought of it as a bug... Not an easy decision at all.
Indeed.
In any case the "sd" namespace shouldn''t be used much in HVM
guest
config files considering that SCSI emulation doesn''t actually work at
the moment.
In fact there is no reason for having sda in an HVM config file, maybe
we should print an error in that case?

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

On 13.07.2011 17:34, Stefano Stabellini wrote:
> On Wed, 13 Jul 2011, Stefan Bader wrote:
>> Yeah, I understand the problem now that I thought of the possibility of
having
>> both name types in the configuration. Though I could imagine that in
reality
>> there will be no one having that done as it would have caused
problems...
>> As you say, the only way to avoid any clashed is to have seperate
namespaces.
>> But that again is unexpected now and people would complain.
>> The 4 letters offset probably still can get busted if someone decides
to use hde
>> and sda. Detecting clashes at allocation time and then using another
name for
>> the duplicate is likely to result in a random of the two to be the
secondary.
>> My feeling would be that trying to map two namespaces into one will
always be
>> confusing and/or failing to some degree. The reason to go back would
only be
>> that this was broken before, so it can probably be expected that people
have
>> avoided that mix.So it would be as it has been before. But I bet there
are other
>> people that thought of it as a bug... Not an easy decision at all.
> 
> Indeed.
> In any case the "sd" namespace shouldn''t be used much in
HVM guest
> config files considering that SCSI emulation doesn''t actually work
at
> the moment.
> In fact there is no reason for having sda in an HVM config file, maybe
> we should print an error in that case?
> 
If it would not be possible to have sd or hd to be present in parallel with xvd
(which is the case with HVM), the xvd driver could just use the names as
requested.
So for HVM they would be called hda in the cfg but sda in the domU.

Wonder whether the simplest approach is not just to try mapping all the old way
starting with xvda and if there is a clash detected bail out complaining and
just call the mix unsupported. Its not as there is a price difference there
using one or the other...
> _______________________________________________
> 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

On Wed, 13 Jul 2011, Stefan Bader wrote:
> On 13.07.2011 17:34, Stefano Stabellini wrote:
> > On Wed, 13 Jul 2011, Stefan Bader wrote:
> >> Yeah, I understand the problem now that I thought of the
possibility of having
> >> both name types in the configuration. Though I could imagine that
in reality
> >> there will be no one having that done as it would have caused
problems...
> >> As you say, the only way to avoid any clashed is to have seperate
namespaces.
> >> But that again is unexpected now and people would complain.
> >> The 4 letters offset probably still can get busted if someone
decides to use hde
> >> and sda. Detecting clashes at allocation time and then using
another name for
> >> the duplicate is likely to result in a random of the two to be the
secondary.
> >> My feeling would be that trying to map two namespaces into one
will always be
> >> confusing and/or failing to some degree. The reason to go back
would only be
> >> that this was broken before, so it can probably be expected that
people have
> >> avoided that mix.So it would be as it has been before. But I bet
there are other
> >> people that thought of it as a bug... Not an easy decision at all.
> > 
> > Indeed.
> > In any case the "sd" namespace shouldn''t be used
much in HVM guest
> > config files considering that SCSI emulation doesn''t actually
work at
> > the moment.
> > In fact there is no reason for having sda in an HVM config file, maybe
> > we should print an error in that case?
> > 
> If it would not be possible to have sd or hd to be present in parallel with
xvd
> (which is the case with HVM), the xvd driver could just use the names as
requested.
> So for HVM they would be called hda in the cfg but sda in the domU.
It is possible to have hd* and xvd* present at the same time in the
config file: it means that you want emulated IDE disks and some PV only
disks (no corresponding emulated interface).
I was only saying that it doesn''t make sense to write sda in an HVM
config file because we don''t currently emulate SCSI or SATA, but in the
future it will become possible.

> Wonder whether the simplest approach is not just to try mapping all the old
way
> starting with xvda and if there is a clash detected bail out complaining
and
> just call the mix unsupported. Its not as there is a price difference there
> using one or the other...
 
Yeah, I am not opposed to it, it is just a matter of changing
EMULATED_SD_DISK_MINOR_OFFSET and EMULATED_SD_DISK_NAME_OFFSET.

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

On 13/07/11 17:19, Stefan Bader wrote:
>
> So for HVM they would be called hda in the cfg but sda in the domU.
Something like this caused a lot of confusion for folks around here:
they were expecting the _name_ used in the cfg to be the name in the
guest, ignoring the fact that neither hdX, xvdX nor sdX ever appear in a
Windows HVM.  Or indeed that, IDE, SCSI and SATA disks are all called
sdX nowadays.

As Stefan said, the name actually only tells you what sort of emulated
controller the disk is attached to: hd for IDE, sd for SCSI and xvd for
PV disks (no actual controller as such).    It might have been better to
have things like IDE(0,0), SCSI(0,3) and XVD(0) and let the guest OS
decide how to map those to names, much like it does for real hardware.

jch

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

On 13.07.2011 19:25, John Haxby wrote:
> On 13/07/11 17:19, Stefan Bader wrote:
>>
>> So for HVM they would be called hda in the cfg but sda in the domU.
> 
> Something like this caused a lot of confusion for folks around here:
> they were expecting the _name_ used in the cfg to be the name in the
> guest, ignoring the fact that neither hdX, xvdX nor sdX ever appear in a
> Windows HVM.  Or indeed that, IDE, SCSI and SATA disks are all called
> sdX nowadays.
> 
> As Stefan said, the name actually only tells you what sort of emulated
> controller the disk is attached to: hd for IDE, sd for SCSI and xvd for
> PV disks (no actual controller as such).    It might have been better to
> have things like IDE(0,0), SCSI(0,3) and XVD(0) and let the guest OS
> decide how to map those to names, much like it does for real hardware.
> 
That seems to be the sad root of the story. If it wasn''t for the fact
that some
naming convention (related to some real kernel names) gets translated into
(emulated) physical connections and the fact that the xvd driver did lie to the
domU (by using a IDE or SCSI major and name), there would be no need to meddle
around it. The faking major,minor,name thing probably was required in the
beginning when there was no other thing than hd* and sd*...

I will post a few patches as replies to this email, one to turn off the offset
and two other things I believe are wrong. But please, better check whether I am
really right there.

For future resolve of this issue, my feeling would be that a naming scheme of
xvsd*, for emulated scsi and xvhd* for emulated ide and xvd* for devices likely
would mean some confusion. Still it sounds like, after a bit of education, the
concept of how names get translated between the cfg and the guest should be
simpler to grasp.
In theory the minor numbers could be even dynamically allocated, but I guess
minors of partitions should always be an offset of the base device and minors of
devices in the same namespace should also be in a way sorted. So maybe a range
of minor numbers reserved for the ide emulated, one for the scsi emulated and
the rest for devices defined as virtual ones sounds like a simple approach.
Anyway, that is just my loud thinking. And maybe not completely thought through.

One other way would be to stop allowing ide or scsi disk names for defining
disks of the virtual controller... Though that might be a bit radical after
allowing it for so long.

-Stefan
> jch
> 
> _______________________________________________
> 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

These were intended to avoid the namespace clash when representing
emulated IDE and SCSI devices. However that seems to confuse users
more than expected (a disk defined as sda becomes xvde).
So for now go back to the scheme which does no adjustments. This
will break when mixing IDE and SCSI names in the configuration of
guests but should be by now expected.

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 drivers/block/xen-blkfront.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2112822..a41530f 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -125,8 +125,8 @@ static DEFINE_SPINLOCK(minor_lock);
 #define BLKIF_MINOR_EXT(dev) ((dev)&(~EXTENDED))
 #define EMULATED_HD_DISK_MINOR_OFFSET (0)
 #define EMULATED_HD_DISK_NAME_OFFSET (EMULATED_HD_DISK_MINOR_OFFSET / 256)
-#define EMULATED_SD_DISK_MINOR_OFFSET (EMULATED_HD_DISK_MINOR_OFFSET + (4 *
16))
-#define EMULATED_SD_DISK_NAME_OFFSET (EMULATED_HD_DISK_NAME_OFFSET + 4)
+#define EMULATED_SD_DISK_MINOR_OFFSET (0)
+#define EMULATED_SD_DISK_NAME_OFFSET (EMULATED_SD_DISK_MINOR_OFFSET / 256)
 
 #define DEV_NAME	"xvd"	/* name in /dev */
 
-- 
1.7.4.1


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

Avoid telling users to use xvde and onwards when using xvde.

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 drivers/block/xen-blkfront.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index a41530f..6e46edb 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -532,7 +532,7 @@ static int xlvbd_alloc_gendisk(blkif_sector_t capacity,
 		minor = BLKIF_MINOR_EXT(info->vdevice);
 		nr_parts = PARTS_PER_EXT_DISK;
 		offset = minor / nr_parts;
-		if (xen_hvm_domain() && offset <= EMULATED_HD_DISK_NAME_OFFSET +
4)
+		if (xen_hvm_domain() && offset < EMULATED_HD_DISK_NAME_OFFSET + 4)
 			printk(KERN_WARNING "blkfront: vdevice 0x%x might conflict with "
 					"emulated IDE disks,\n\t choose an xvd device name"
 					"from xvde on\n", info->vdevice);
-- 
1.7.4.1


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

Before this a block device defined as hda1 in the configuration files
would be mapped to hda, as well as hda2.

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 drivers/block/xen-blkfront.c |   12 +++++++-----
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 6e46edb..77489f1 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -449,15 +449,17 @@ static int xen_translate_vdev(int vdevice, int *minor,
unsigned int *offset)
 	major = BLKIF_MAJOR(vdevice);
 	*minor = BLKIF_MINOR(vdevice);
 	switch (major) {
+		/* For IDE the assumption seems to be 64 partitions (including
+		 * the whole device) per disk. */
 		case XEN_IDE0_MAJOR:
 			*offset = (*minor / 64) + EMULATED_HD_DISK_NAME_OFFSET;
-			*minor = ((*minor / 64) * PARTS_PER_DISK) +
-				EMULATED_HD_DISK_MINOR_OFFSET;
+			*minor = *minor + EMULATED_HD_DISK_MINOR_OFFSET;
 			break;
 		case XEN_IDE1_MAJOR:
-			*offset = (*minor / 64) + 2 + EMULATED_HD_DISK_NAME_OFFSET;
-			*minor = (((*minor / 64) + 2) * PARTS_PER_DISK) +
-				EMULATED_HD_DISK_MINOR_OFFSET;
+			*offset = (*minor / 64) + 2 +
+				  EMULATED_HD_DISK_NAME_OFFSET;
+			*minor = *minor + (2 * 64) +
+				 EMULATED_HD_DISK_MINOR_OFFSET;
 			break;
 		case XEN_SCSI_DISK0_MAJOR:
 			*offset = (*minor / PARTS_PER_DISK) + EMULATED_SD_DISK_NAME_OFFSET;
-- 
1.7.4.1


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

On Thu, 2011-07-14 at 14:26 +0100, Stefan Bader wrote:
> On 13.07.2011 19:25, John Haxby wrote:
> > On 13/07/11 17:19, Stefan Bader wrote:
> >>
> >> So for HVM they would be called hda in the cfg but sda in the
domU.
> > 
> > Something like this caused a lot of confusion for folks around here:
> > they were expecting the _name_ used in the cfg to be the name in the
> > guest, ignoring the fact that neither hdX, xvdX nor sdX ever appear in
a
> > Windows HVM.  Or indeed that, IDE, SCSI and SATA disks are all called
> > sdX nowadays.
> > 
> > As Stefan said, the name actually only tells you what sort of emulated
> > controller the disk is attached to: hd for IDE, sd for SCSI and xvd
for
> > PV disks (no actual controller as such).    It might have been better
to
> > have things like IDE(0,0), SCSI(0,3) and XVD(0) and let the guest OS
> > decide how to map those to names, much like it does for real hardware.
> > 
> 
> That seems to be the sad root of the story. If it wasn''t for the
fact that some
> naming convention (related to some real kernel names) gets translated into
> (emulated) physical connections and the fact that the xvd driver did lie to
the
> domU (by using a IDE or SCSI major and name), there would be no need to
meddle
> around it. The faking major,minor,name thing probably was required in the
> beginning when there was no other thing than hd* and sd*...
> 
> I will post a few patches as replies to this email, one to turn off the
offset
> and two other things I believe are wrong. But please, better check whether
I am
> really right there.
> 
> For future resolve of this issue, my feeling would be that a naming scheme
of
> xvsd*, for emulated scsi and xvhd* for emulated ide and xvd* for devices
likely
> would mean some confusion. Still it sounds like, after a bit of education,
the
> concept of how names get translated between the cfg and the guest should be
> simpler to grasp.
Have you seen docs/misc/vbd-interface.txt? It clarifies (or at least
tries to) some of this stuff. If there are things which could be
improved (esp. from the end-user perspective) there then patches would
be gratefully accepted.
> In theory the minor numbers could be even dynamically allocated, but I
guess
> minors of partitions should always be an offset of the base device and
minors of
> devices in the same namespace should also be in a way sorted. So maybe a
range
> of minor numbers reserved for the ide emulated, one for the scsi emulated
and
> the rest for devices defined as virtual ones sounds like a simple approach.
> Anyway, that is just my loud thinking. And maybe not completely thought
through.
> 
> One other way would be to stop allowing ide or scsi disk names for defining
> disks of the virtual controller... Though that might be a bit radical after
> allowing it for so long.
Personally I think it would be great but I don''t think its feasible.
I''ve been trying to encourage the use of xvd* for years :-/.

Ian.
> 
> -Stefan
> 
> > jch
> > 
> > _______________________________________________
> > 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

Stefan Bader writes ("Re: [Xen-devel] Re: Question on "xen-blkfront:
handle Xen major	numbers other than XENVBD""):
> Yeah, I understand the problem now that I thought of the possibility
> of having both name types in the configuration. Though I could
> imagine that in reality there will be no one having that done as it
> would have caused problems...  As you say, the only way to avoid any
> clashed is to have seperate namespaces.  But that again is
> unexpected now and people would complain.  The 4 letters offset
> probably still can get busted if someone decides to use hde and sda.
Nowadays people supply hd* because they''re using HVM (and thus the
clashes happen with PV-on-HVM).  hde doesn''t work for HVM because
there are only two two-channel ide controllers emulated in qemu-dm.

So I don''t think this is an important configuration.
> Detecting clashes at allocation time and then using another name for
> the duplicate is likely to result in a random of the two to be the
> secondary.  My feeling would be that trying to map two namespaces
> into one will always be confusing and/or failing to some degree. The
> reason to go back would only be that this was broken before, so it
> can probably be expected that people have avoided that mix. So it
> would be as it has been before. But I bet there are other people
> that thought of it as a bug... Not an easy decision at all.
I think at this stage the best thing to do would be to leave Linux 3.x
as it is rather than changing things again.

Ian.

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

On 14.07.2011 16:14, Ian Campbell wrote:
> On Thu, 2011-07-14 at 14:26 +0100, Stefan Bader wrote:
>> On 13.07.2011 19:25, John Haxby wrote:
>>> On 13/07/11 17:19, Stefan Bader wrote:
>>>>
>>>> So for HVM they would be called hda in the cfg but sda in the
domU.
>>>
>>> Something like this caused a lot of confusion for folks around
here:
>>> they were expecting the _name_ used in the cfg to be the name in
the
>>> guest, ignoring the fact that neither hdX, xvdX nor sdX ever appear
in a
>>> Windows HVM.  Or indeed that, IDE, SCSI and SATA disks are all
called
>>> sdX nowadays.
>>>
>>> As Stefan said, the name actually only tells you what sort of
emulated
>>> controller the disk is attached to: hd for IDE, sd for SCSI and xvd
for
>>> PV disks (no actual controller as such).    It might have been
better to
>>> have things like IDE(0,0), SCSI(0,3) and XVD(0) and let the guest
OS
>>> decide how to map those to names, much like it does for real
hardware.
>>>
>>
>> That seems to be the sad root of the story. If it wasn''t for
the fact that some
>> naming convention (related to some real kernel names) gets translated
into
>> (emulated) physical connections and the fact that the xvd driver did
lie to the
>> domU (by using a IDE or SCSI major and name), there would be no need to
meddle
>> around it. The faking major,minor,name thing probably was required in
the
>> beginning when there was no other thing than hd* and sd*...
>>
>> I will post a few patches as replies to this email, one to turn off the
offset
>> and two other things I believe are wrong. But please, better check
whether I am
>> really right there.
>>
>> For future resolve of this issue, my feeling would be that a naming
scheme of
>> xvsd*, for emulated scsi and xvhd* for emulated ide and xvd* for
devices likely
>> would mean some confusion. Still it sounds like, after a bit of
education, the
>> concept of how names get translated between the cfg and the guest
should be
>> simpler to grasp.
> 
> Have you seen docs/misc/vbd-interface.txt? It clarifies (or at least
> tries to) some of this stuff. If there are things which could be
> improved (esp. from the end-user perspective) there then patches would
> be gratefully accepted.
> 
No, I must admit I had not (as my approach is is more from the kernel side). But
thanks for pointing towards that. I will have a read there.
>> In theory the minor numbers could be even dynamically allocated, but I
guess
>> minors of partitions should always be an offset of the base device and
minors of
>> devices in the same namespace should also be in a way sorted. So maybe
a range
>> of minor numbers reserved for the ide emulated, one for the scsi
emulated and
>> the rest for devices defined as virtual ones sounds like a simple
approach.
>> Anyway, that is just my loud thinking. And maybe not completely thought
through.
>>
>> One other way would be to stop allowing ide or scsi disk names for
defining
>> disks of the virtual controller... Though that might be a bit radical
after
>> allowing it for so long.
> 
> Personally I think it would be great but I don''t think its
feasible.
> I''ve been trying to encourage the use of xvd* for years :-/.
>
Unfortunately its always hard to convince people if something seems to work. And
it can be hard to argue people are wrong when they complain about the latest
change of preserving xvda-d for hd* mapping in 3.0. :(

-Stefan
> Ian.
> 
>>
>> -Stefan
>>
>>> jch
>>>
>>> _______________________________________________
>>> 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

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

On Thu, 14 Jul 2011, Stefan Bader wrote:
> These were intended to avoid the namespace clash when representing
> emulated IDE and SCSI devices. However that seems to confuse users
> more than expected (a disk defined as sda becomes xvde).
> So for now go back to the scheme which does no adjustments. This
> will break when mixing IDE and SCSI names in the configuration of
> guests but should be by now expected.
This patch is fine by me.

> 
> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
> ---
>  drivers/block/xen-blkfront.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2112822..a41530f 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -125,8 +125,8 @@ static DEFINE_SPINLOCK(minor_lock);
>  #define BLKIF_MINOR_EXT(dev) ((dev)&(~EXTENDED))
>  #define EMULATED_HD_DISK_MINOR_OFFSET (0)
>  #define EMULATED_HD_DISK_NAME_OFFSET (EMULATED_HD_DISK_MINOR_OFFSET / 256)
> -#define EMULATED_SD_DISK_MINOR_OFFSET (EMULATED_HD_DISK_MINOR_OFFSET + (4
* 16))
> -#define EMULATED_SD_DISK_NAME_OFFSET (EMULATED_HD_DISK_NAME_OFFSET + 4)
> +#define EMULATED_SD_DISK_MINOR_OFFSET (0)
> +#define EMULATED_SD_DISK_NAME_OFFSET (EMULATED_SD_DISK_MINOR_OFFSET / 256)
>  
>  #define DEV_NAME	"xvd"	/* name in /dev */
>  
> -- 
> 1.7.4.1
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 14 Jul 2011, Stefan Bader wrote:
> Avoid telling users to use xvde and onwards when using xvde.
Also fine by me.

> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
> ---
>  drivers/block/xen-blkfront.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index a41530f..6e46edb 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -532,7 +532,7 @@ static int xlvbd_alloc_gendisk(blkif_sector_t capacity,
>  		minor = BLKIF_MINOR_EXT(info->vdevice);
>  		nr_parts = PARTS_PER_EXT_DISK;
>  		offset = minor / nr_parts;
> -		if (xen_hvm_domain() && offset <=
EMULATED_HD_DISK_NAME_OFFSET + 4)
> +		if (xen_hvm_domain() && offset < EMULATED_HD_DISK_NAME_OFFSET
+ 4)
>  			printk(KERN_WARNING "blkfront: vdevice 0x%x might conflict with
"
>  					"emulated IDE disks,\n\t choose an xvd device name"
>  					"from xvde on\n", info->vdevice);
> -- 
> 1.7.4.1
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 14 Jul 2011, Stefan Bader wrote:
> Before this a block device defined as hda1 in the configuration files
> would be mapped to hda, as well as hda2.
> 
Don''t you mean xvda and xvda2?

Besides hda1 doesn''t mean anything for an HVM guest, it is not an
allowed disk configuration.
It is also a bug in the toolstack that propagates such nonsense to
xenstore so I would rather fix xend and/or libxenlight.

> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
> ---
>  drivers/block/xen-blkfront.c |   12 +++++++-----
>  1 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 6e46edb..77489f1 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -449,15 +449,17 @@ static int xen_translate_vdev(int vdevice, int
*minor, unsigned int *offset)
>  	major = BLKIF_MAJOR(vdevice);
>  	*minor = BLKIF_MINOR(vdevice);
>  	switch (major) {
> +		/* For IDE the assumption seems to be 64 partitions (including
> +		 * the whole device) per disk. */
>  		case XEN_IDE0_MAJOR:
>  			*offset = (*minor / 64) + EMULATED_HD_DISK_NAME_OFFSET;
> -			*minor = ((*minor / 64) * PARTS_PER_DISK) +
> -				EMULATED_HD_DISK_MINOR_OFFSET;
> +			*minor = *minor + EMULATED_HD_DISK_MINOR_OFFSET;
>  			break;
>  		case XEN_IDE1_MAJOR:
> -			*offset = (*minor / 64) + 2 + EMULATED_HD_DISK_NAME_OFFSET;
> -			*minor = (((*minor / 64) + 2) * PARTS_PER_DISK) +
> -				EMULATED_HD_DISK_MINOR_OFFSET;
> +			*offset = (*minor / 64) + 2 +
> +				  EMULATED_HD_DISK_NAME_OFFSET;
> +			*minor = *minor + (2 * 64) +
> +				 EMULATED_HD_DISK_MINOR_OFFSET;
>  			break;
>  		case XEN_SCSI_DISK0_MAJOR:
>  			*offset = (*minor / PARTS_PER_DISK) + EMULATED_SD_DISK_NAME_OFFSET;
> -- 
> 1.7.4.1
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 14.07.2011 19:34, Stefano Stabellini wrote:
> On Thu, 14 Jul 2011, Stefan Bader wrote:
>> Before this a block device defined as hda1 in the configuration files
>> would be mapped to hda, as well as hda2.
>>
> 
> Don''t you mean xvda and xvda2?
> 
Bah, yes, you are right. I had a "hda1" in a PVM guests definition and
within
the guest it had become "xvda". Basically it seems that the current
code would
map any minor number between 0-63 to 0.
> Besides hda1 doesn''t mean anything for an HVM guest, it is not an
> allowed disk configuration.
> It is also a bug in the toolstack that propagates such nonsense to
> xenstore so I would rather fix xend and/or libxenlight.
>
Which seems actually to be something that could be intentional for HVM guests.
As you say, "hdaX" does make no sense there... Unfortunately this is
shared for
PVM and HVM. So my change may make sense with the first but not the latter... :(
> 
>> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
>> ---
>>  drivers/block/xen-blkfront.c |   12 +++++++-----
>>  1 files changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkfront.c
b/drivers/block/xen-blkfront.c
>> index 6e46edb..77489f1 100644
>> --- a/drivers/block/xen-blkfront.c
>> +++ b/drivers/block/xen-blkfront.c
>> @@ -449,15 +449,17 @@ static int xen_translate_vdev(int vdevice, int
*minor, unsigned int *offset)
>>  	major = BLKIF_MAJOR(vdevice);
>>  	*minor = BLKIF_MINOR(vdevice);
>>  	switch (major) {
>> +		/* For IDE the assumption seems to be 64 partitions (including
>> +		 * the whole device) per disk. */
>>  		case XEN_IDE0_MAJOR:
>>  			*offset = (*minor / 64) + EMULATED_HD_DISK_NAME_OFFSET;
>> -			*minor = ((*minor / 64) * PARTS_PER_DISK) +
>> -				EMULATED_HD_DISK_MINOR_OFFSET;
>> +			*minor = *minor + EMULATED_HD_DISK_MINOR_OFFSET;
>>  			break;
>>  		case XEN_IDE1_MAJOR:
>> -			*offset = (*minor / 64) + 2 + EMULATED_HD_DISK_NAME_OFFSET;
>> -			*minor = (((*minor / 64) + 2) * PARTS_PER_DISK) +
>> -				EMULATED_HD_DISK_MINOR_OFFSET;
>> +			*offset = (*minor / 64) + 2 +
>> +				  EMULATED_HD_DISK_NAME_OFFSET;
>> +			*minor = *minor + (2 * 64) +
>> +				 EMULATED_HD_DISK_MINOR_OFFSET;
>>  			break;
>>  		case XEN_SCSI_DISK0_MAJOR:
>>  			*offset = (*minor / PARTS_PER_DISK) + EMULATED_SD_DISK_NAME_OFFSET;
>> -- 
>> 1.7.4.1
>>

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

On Fri, 15 Jul 2011, Stefan Bader wrote:
> On 14.07.2011 19:34, Stefano Stabellini wrote:
> > On Thu, 14 Jul 2011, Stefan Bader wrote:
> >> Before this a block device defined as hda1 in the configuration
files
> >> would be mapped to hda, as well as hda2.
> >>
> > 
> > Don''t you mean xvda and xvda2?
> > 
> Bah, yes, you are right. I had a "hda1" in a PVM guests
definition and within
> the guest it had become "xvda". Basically it seems that the
current code would
> map any minor number between 0-63 to 0.
That would be correct because hda1 is not allowed, the closest thing to
a valid configuration would be hda and therefore xvda.

> > Besides hda1 doesn''t mean anything for an HVM guest, it is
not an
> > allowed disk configuration.
> > It is also a bug in the toolstack that propagates such nonsense to
> > xenstore so I would rather fix xend and/or libxenlight.
> >
> Which seems actually to be something that could be intentional for HVM
guests.
> As you say, "hdaX" does make no sense there... Unfortunately this
is shared for
> PVM and HVM. So my change may make sense with the first but not the
latter... :(
I see. The source of the problem is ancient disk configuration lines in
PV config files: like Ian wrote before, people should be using xvd* only
in PV guests config file, rather than hd* or sd*...
I think the best thing to do here would be to catch the error at the
toolstack level.

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

On 15.07.2011 12:20, Stefano Stabellini wrote:
> On Fri, 15 Jul 2011, Stefan Bader wrote:
>> On 14.07.2011 19:34, Stefano Stabellini wrote:
>>> On Thu, 14 Jul 2011, Stefan Bader wrote:
>>>> Before this a block device defined as hda1 in the configuration
files
>>>> would be mapped to hda, as well as hda2.
>>>>
>>>
>>> Don''t you mean xvda and xvda2?
>>>
>> Bah, yes, you are right. I had a "hda1" in a PVM guests
definition and within
>> the guest it had become "xvda". Basically it seems that the
current code would
>> map any minor number between 0-63 to 0.
> 
> That would be correct because hda1 is not allowed, the closest thing to
> a valid configuration would be hda and therefore xvda.
> 
I see. So sort of fixing up when there is an invalid HVM configuration.
> 
>>> Besides hda1 doesn''t mean anything for an HVM guest, it is
not an
>>> allowed disk configuration.
>>> It is also a bug in the toolstack that propagates such nonsense to
>>> xenstore so I would rather fix xend and/or libxenlight.
>>>
>> Which seems actually to be something that could be intentional for HVM
guests.
>> As you say, "hdaX" does make no sense there... Unfortunately
this is shared for
>> PVM and HVM. So my change may make sense with the first but not the
latter... :(
> 
> I see. The source of the problem is ancient disk configuration lines in
> PV config files: like Ian wrote before, people should be using xvd* only
> in PV guests config file, rather than hd* or sd*...
> I think the best thing to do here would be to catch the error at the
> toolstack level.
In that case it was not even a real use-case. I was just trying to see what
happens. Though I assume if you _can_ do it, there _will_ be someone doing so...

Sounds like both cases would be candidates for the toolstack. But for the kernel
patch I made, there is no reason and it should be ignored. Breaking one case for
another is not that much of use.

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

On Thu, Jul 14, 2011 at 03:30:47PM +0200, Stefan Bader
wrote:
> Before this a block device defined as hda1 in the configuration files
> would be mapped to hda, as well as hda2.
Pulled patch 1,2, and dropped this one.
> 
> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
> ---
>  drivers/block/xen-blkfront.c |   12 +++++++-----
>  1 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 6e46edb..77489f1 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -449,15 +449,17 @@ static int xen_translate_vdev(int vdevice, int
*minor, unsigned int *offset)
>  	major = BLKIF_MAJOR(vdevice);
>  	*minor = BLKIF_MINOR(vdevice);
>  	switch (major) {
> +		/* For IDE the assumption seems to be 64 partitions (including
> +		 * the whole device) per disk. */
>  		case XEN_IDE0_MAJOR:
>  			*offset = (*minor / 64) + EMULATED_HD_DISK_NAME_OFFSET;
> -			*minor = ((*minor / 64) * PARTS_PER_DISK) +
> -				EMULATED_HD_DISK_MINOR_OFFSET;
> +			*minor = *minor + EMULATED_HD_DISK_MINOR_OFFSET;
>  			break;
>  		case XEN_IDE1_MAJOR:
> -			*offset = (*minor / 64) + 2 + EMULATED_HD_DISK_NAME_OFFSET;
> -			*minor = (((*minor / 64) + 2) * PARTS_PER_DISK) +
> -				EMULATED_HD_DISK_MINOR_OFFSET;
> +			*offset = (*minor / 64) + 2 +
> +				  EMULATED_HD_DISK_NAME_OFFSET;
> +			*minor = *minor + (2 * 64) +
> +				 EMULATED_HD_DISK_MINOR_OFFSET;
>  			break;
>  		case XEN_SCSI_DISK0_MAJOR:
>  			*offset = (*minor / PARTS_PER_DISK) + EMULATED_SD_DISK_NAME_OFFSET;
> -- 
> 1.7.4.1
> 
> 
> _______________________________________________
> 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

Alpha 2 already has Xen 4.1 packaged and ready for testing.
It appears to be known bug that HVM  DomUs crash at Xen 4.1 Dom0 with different
"pvops''''
kernels ( in particular 3.0.0-5-generic Ubuntu) , but not only on Ubuntu .
Here is report for Fedora 15 :

http://www.gossamer-threads.com/lists/xen/users/213049?nohighlight=1#213049

Ubuntu developers are pretty sure that Xen Host will be built with no problems.
Would it  be possible to issue a patch for Xen  4.1 to fix the  problem ?
Actually two distros are affected Fedora 16 and Ubuntu 11.10 ( maybe Debian  -
here
i am not sure )

Boris.






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

On Tue, Jul 19, 2011 at 09:22:13AM -0700, Boris Derzhavets
wrote:
> Alpha 2 already has Xen 4.1 packaged and ready for testing.
> It appears to be known bug that HVM  DomUs crash at Xen 4.1 Dom0 with
different "pvops''''
> kernels ( in particular 3.0.0-5-generic Ubuntu) , but not only on Ubuntu .
> Here is report for Fedora 15 :
> 
> http://www.gossamer-threads.com/lists/xen/users/213049?nohighlight=1#213049
> 
> Ubuntu developers are pretty sure that Xen Host will be built with no
problems.
> Would it  be possible to issue a patch for Xen  4.1 to fix the  problem ?
Well, we can''t reproduce this. You need to help us out here. How did
you install
Xen 4.1? Did you uninstall the _old_ version of Xen you had on your machine? If
yes,
how?

So _which_ kernels/distros do work for you? I am really confused by your
emails (you say F15 is not working, but the thread is about F14).
> Actually two distros are affected Fedora 16 and Ubuntu 11.10 ( maybe
Debian  - here
> i am not sure )
Wait, so is F16 (rawhide) also affected?
> 
> Boris.
> 
> 
> 
> 
> _______________________________________________
> 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

On Tue, 19 Jul 2011, Boris Derzhavets wrote:
> Alpha 2 already has Xen 4.1 packaged and ready for testing.
> It appears to be known bug that HVM  DomUs crash at Xen 4.1 Dom0 with
different "pvops''''
> kernels ( in particular 3.0.0-5-generic Ubuntu) , but not only on Ubuntu .
> Here is report for Fedora 15 :
> 
> http://www.gossamer-threads.com/lists/xen/users/213049?nohighlight=1#213049
> 
> Ubuntu developers are pretty sure that Xen Host will be built with no
problems.
> Would it  be possible to issue a patch for Xen  4.1 to fix the  problem ?
> Actually two distros are affected Fedora 16 and Ubuntu 11.10 ( maybe
Debian  - here
> i am not sure )
First we need to understand what the problem is. I wasn''t aware of this
issue before you started a thread yesterday and nothing meaningful
appears in any of the logs posted.

Now I am trying to reproduce the problem but so far I didn''t have any
luck: I am testing with the same kernel config and VM config you use
with plain Linux 3.0.0 rc7, I tried both xen 4.1.0 and xen 4.1.1 but I
still can start hvm guests with no troubles.

However all my tests are on Debian 6.0.1, I am downloading alpha 2 to
see if I can reproduce the bug there.
--8323329-693837394-1311093457=:12963
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--8323329-693837394-1311093457=:12963--

> Well, we can''t reproduce this. You need to help us out here. How
did you install
> Xen 4.1? Did you uninstall the _old_ version of Xen you had on your
machine? If yes,
> how?
I installed Xen 4.1 and tools via system Manager - Synaptic Manager. It created
automatically grub2 entry for Xen.   I do have Xen Host to create and run PV
domUs
F15,F14,SL 6.  Moreover F15 and SL6 ( this one pretty smoothly ) may be
installed
via Virt-manager ( Libvirt 0.9.2). F14 in text mode, but this is not a problem
to start
vncserver at DomU.
That is my environment :-
*******************************************************************************************************
root@boris-P5Q-E:~# xm info
host                   : boris-P5Q-E
release                : 3.0.0-5-generic
version                : #6-Ubuntu SMP Tue Jul 12 05:21:50 UTC 2011
machine                : x86_64
nr_cpus                : 2
nr_nodes               : 1
cores_per_socket       : 2
threads_per_core       : 1
cpu_mhz                : 2999
hw_caps                :
bfebfbff:20100800:00000000:00000940:0008e3fd:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 8191
free_memory            : 2078
free_cpus              : 0
xen_major              : 4
xen_minor              : 1
xen_extra              : .0
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : placeholder
cc_compiler            : gcc version 4.6.1 (Ubuntu/Linaro 4.6.0-10ubuntu2)
cc_compile_by          : zulcss
cc_compile_domain      : ubuntu.com
cc_compile_date        : Sat Jun  4 19:41:05 UTC 2011
xend_config_format     : 4
**************************************************************************************************
As soon as i try create create HVM DomU via standard profile. It even
doesn''t start. Nothing
is listening at localhost:5900

> So _which_ kernels/distros do work for you?
No one.
> I am really confused by your emails (you say F15 is not working, but the
thread is about F14).
Thread  -   Per Jim@bellsouth :

According to several threads, such as mine last month - ''[Xen-users]
Working with Fedora 15 & systemd'' - and ''[Xen-users]
Problems
with HVM after upgrade from 4.0.1 to 4.1.1'', and a private
communication with
t.wagner in ''[Xen-users] XEN-4.1.1 and linux kernel 3.0-rc5'',
and finally
''[Xen-users] Re: Trouble starting HVM domU with Linux 3.0.0 and Xen
4.1.1'',

hvm & xen 4.1.x don''t mix, either with kernel 3.0.0, or pvops
2.6.32 (which
was working with xen 4.0.2 prior to upgrading from fedora 14 to f15, and xen
4.1. In the last thread mentioned above, the solution was to upgrade to xen
4.2 unstable. My equally effective solution was to downgrade to xen 4.0.2,
since fedora rawhide doesn''t have 4.2 yet.



Finally, from the Net comes the info that Xen 4.1 with 3.0.0-rc6 kernel creates
Dom0
with no HVMs possible. No matter on top of what Linux this Dom0 lives.

In my case :
Ubuntu 11.10 alpha2 + upgrades up to 07/18/11

Boris.
P.S.     I tested Xen 4.2 Unstable ( same kernel 3.0.0.5-generic) on top of
Ubuntu 11.10.
            HVM does work. It''s easy to install and run as usual

--- On Tue, 7/19/11, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot)
(HVM DomUs crash)
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: xen-devel@lists.xensource.com, "Stefano Stabellini"
<stefano.stabellini@eu.citrix.com>
Date: Tuesday, July 19, 2011, 1:09 PM

On Tue, Jul 19, 2011 at 09:22:13AM -0700, Boris Derzhavets
wrote:
> Alpha 2 already has Xen 4.1 packaged and ready for testing.
> It appears to be known bug that HVM  DomUs crash at Xen 4.1 Dom0 with
different "pvops''''
> kernels ( in particular 3.0.0-5-generic Ubuntu) , but not only on Ubuntu .
> Here is report for Fedora 15 :
> 
> http://www.gossamer-threads.com/lists/xen/users/213049?nohighlight=1#213049
> 
> Ubuntu developers are pretty sure that Xen Host will be built with no
problems.
> Would it  be possible to issue a patch for Xen  4.1 to fix the  problem ?
Well, we can''t reproduce this. You need to help us out here. How did
you install
Xen 4.1? Did you uninstall the _old_ version of Xen you had on your machine? If
yes,
how?

So _which_ kernels/distros do work for you? I am really confused by your
emails (you say F15 is not working, but the thread is about F14).
> Actually two distros are affected Fedora 16 and Ubuntu 11.10 ( maybe
Debian  - here
> i am not sure )
Wait, so is F16 (rawhide) also affected?
> 
> Boris.
> 
> 
> 
> 
> _______________________________________________
> 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

On Tue, 19 Jul 2011, Stefano Stabellini wrote:
> On Tue, 19 Jul 2011, Boris Derzhavets wrote:
> > Alpha 2 already has Xen 4.1 packaged and ready for testing.
> > It appears to be known bug that HVM  DomUs crash at Xen 4.1 Dom0 with
different "pvops''''
> > kernels ( in particular 3.0.0-5-generic Ubuntu) , but not only on
Ubuntu .
> > Here is report for Fedora 15 :
> > 
> >
http://www.gossamer-threads.com/lists/xen/users/213049?nohighlight=1#213049
> > 
> > Ubuntu developers are pretty sure that Xen Host will be built with no
problems.
> > Would it  be possible to issue a patch for Xen  4.1 to fix the 
problem ?
> > Actually two distros are affected Fedora 16 and Ubuntu 11.10 ( maybe
Debian  - here
> > i am not sure )
> 
> First we need to understand what the problem is. I wasn''t aware of
this
> issue before you started a thread yesterday and nothing meaningful
> appears in any of the logs posted.
> 
> Now I am trying to reproduce the problem but so far I didn''t have
any
> luck: I am testing with the same kernel config and VM config you use
> with plain Linux 3.0.0 rc7, I tried both xen 4.1.0 and xen 4.1.1 but I
> still can start hvm guests with no troubles.
> 
> However all my tests are on Debian 6.0.1, I am downloading alpha 2 to
> see if I can reproduce the bug there.

I managed to repro the issue on alpha 2.
These are the error logs that I get on the xen serial when starting an
HVM guest:

(XEN) HVM1: HVM Loader
(XEN) io.c:194:d1 MMIO emulation failed @ 0018:9ffff: 00 e0 de be 00 83
(XEN) hvm.c:1099:d1 Triple fault on VCPU0 - invoking HVM system reset.

The problem appears to be hvmloader, in fact I replaced the hvmloader
that comes with ubuntu alpha 2 with the one I compiled myself out of xen
4.1.1 and everything worked as expected.
Do you have any patches to xen that might have broken hvmloader?
--8323329-593097064-1311098519=:12963
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--8323329-593097064-1311098519=:12963--

I downloaded and installed  source . Went to  xen-4.0.1/debian/patches.
It contains *.patch  and *.diff files listed in file series ( to apply) .

First i tried 
# cat  *.patch | grep hvmloader
# cat   *.diff     | grep hvmloader

All what i was able find :-

In file tools-python-xen-relative-path.diff 

         elif vals.kernel == ''hvmloader'':
             # Keep hvmloader w/o a path and let xend find it.
-        elif vals.loader == ''hvmloader'':
+        if vals.loader == ''hvmloader'':
             # Keep hvmloader w/o a path and let xend find it.
                 # Old configs may have hvmloader set as PV_kernel param
                     if self[''PV_kernel''] ==
''hvmloader'':
-                        self[''PV_kernel''] =
auxbin.pathTo("hvmloader")
+                        self[''PV_kernel''] =
auxbin.path_boot("hvmloader")
-                   
self[''platform''][''loader''] =
auxbin.pathTo("hvmloader")
+                   
self[''platform''][''loader''] =
auxbin.path_boot("hvmloader")
             elif self[''platform''][''loader'']
== ''hvmloader'':
-                self[''platform''][''loader'']
= auxbin.pathTo("hvmloader")
+                self[''platform''][''loader'']
= auxbin.path_boot("hvmloader")

So, Ubuntu doesn''t touch original source of "hvmloader"
coming with  xen-4.1.0.tar.gz

Boris.


--- On Tue, 7/19/11, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot)
(HVM DomUs crash)
To: "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
Cc: "Boris Derzhavets" <bderzhavets@yahoo.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Keir Fraser" <keir@xen.org>, "Konrad Rzeszutek Wilk"
<konrad.wilk@oracle.com>
Date: Tuesday, July 19, 2011, 2:01 PM

On Tue, 19 Jul 2011, Stefano Stabellini wrote:
> On Tue, 19 Jul 2011, Boris Derzhavets wrote:
> > Alpha 2 already has Xen 4.1 packaged and ready for testing.
> > It appears to be known bug that HVM  DomUs crash at Xen 4.1 Dom0 with
different "pvops''''
> > kernels ( in particular 3.0.0-5-generic Ubuntu) , but not only on
Ubuntu .
> > Here is report for Fedora 15 :
> > 
> >
http://www.gossamer-threads.com/lists/xen/users/213049?nohighlight=1#213049
> > 
> > Ubuntu developers are pretty sure that Xen Host will be built with no
problems.
> > Would it  be possible to issue a patch for Xen  4.1 to fix the 
problem ?
> > Actually two distros are affected Fedora 16 and Ubuntu 11.10 ( maybe
Debian  - here
> > i am not sure )
> 
> First we need to understand what the problem is. I wasn''t aware of
this
> issue before you started a thread yesterday and nothing meaningful
> appears in any of the logs posted.
> 
> Now I am trying to reproduce the problem but so far I didn''t have
any
> luck: I am testing with the same kernel config and VM config you use
> with plain Linux 3.0.0 rc7, I tried both xen 4.1.0 and xen 4.1.1 but I
> still can start hvm guests with no troubles.
> 
> However all my tests are on Debian 6.0.1, I am downloading alpha 2 to
> see if I can reproduce the bug there.

I managed to repro the issue on alpha 2.
These are the error logs that I get on the xen serial when starting an
HVM guest:

(XEN) HVM1: HVM Loader
(XEN) io.c:194:d1 MMIO emulation failed @ 0018:9ffff: 00 e0 de be 00 83
(XEN) hvm.c:1099:d1 Triple fault on VCPU0 - invoking HVM system reset.

The problem appears to be hvmloader, in fact I replaced the hvmloader
that comes with ubuntu alpha 2 with the one I compiled myself out of xen
4.1.1 and everything worked as expected.
Do you have any patches to xen that might have broken hvmloader?
-----Inline Attachment Follows-----

_______________________________________________
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

Yes, hvmloader been built under xen-unstable.hg on the same alpha 2, works fine
been copied  to   /usr/lib/xen-4.1/boot/

root@boris-P5Q-E:/usr/lib/xen-4.1/boot# ls -l
total 992
-rw-r--r-- 1 root root 544700 2011-07-19 23:27 hvmloader
-rw-r--r-- 1 root root 470985 2011-06-04 23:42 hvmloader.orig

Boris

--- On Tue, 7/19/11, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot)
(HVM DomUs crash)
To: "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
Cc: "Boris Derzhavets" <bderzhavets@yahoo.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Keir Fraser" <keir@xen.org>, "Konrad Rzeszutek Wilk"
<konrad.wilk@oracle.com>
Date: Tuesday, July 19, 2011, 2:01 PM

On Tue, 19 Jul 2011, Stefano Stabellini wrote:
> On Tue, 19 Jul 2011, Boris Derzhavets wrote:
> > Alpha 2 already has Xen 4.1 packaged and ready for testing.
> > It appears to be known bug that HVM  DomUs crash at Xen 4.1 Dom0 with
different "pvops''''
> > kernels ( in particular 3.0.0-5-generic Ubuntu) , but not only on
Ubuntu .
> > Here is report for Fedora 15 :
> > 
> >
http://www.gossamer-threads.com/lists/xen/users/213049?nohighlight=1#213049
> > 
> > Ubuntu developers are pretty sure that Xen Host will be built with no
problems.
> > Would it  be possible to issue a patch for Xen  4.1 to fix the 
problem ?
> > Actually two distros are affected Fedora 16 and Ubuntu 11.10 ( maybe
Debian  - here
> > i am not sure )
> 
> First we need to understand what the problem is. I wasn''t aware of
this
> issue before you started a thread yesterday and nothing meaningful
> appears in any of the logs posted.
> 
> Now I am trying to reproduce the problem but so far I didn''t have
any
> luck: I am testing with the same kernel config and VM config you use
> with plain Linux 3.0.0 rc7, I tried both xen 4.1.0 and xen 4.1.1 but I
> still can start hvm guests with no troubles.
> 
> However all my tests are on Debian 6.0.1, I am downloading alpha 2 to
> see if I can reproduce the bug there.

I managed to repro the issue on alpha 2.
These are the error logs that I get on the xen serial when starting an
HVM guest:

(XEN) HVM1: HVM Loader
(XEN) io.c:194:d1 MMIO emulation failed @ 0018:9ffff: 00 e0 de be 00 83
(XEN) hvm.c:1099:d1 Triple fault on VCPU0 - invoking HVM system reset.

The problem appears to be hvmloader, in fact I replaced the hvmloader
that comes with ubuntu alpha 2 with the one I compiled myself out of xen
4.1.1 and everything worked as expected.
Do you have any patches to xen that might have broken hvmloader?
-----Inline Attachment Follows-----

_______________________________________________
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

On Tue, 2011-07-19 at 20:01 +0100, Boris Derzhavets
wrote:
> I downloaded and installed  source . Went to
> xen-4.0.1/debian/patches.
But Oneiric Ocelot contains Xen 4.1.1 (according to
http://packages.ubuntu.com/oneiric/kernel/) and not xen-4.0.1. AFAICT
there is quite a bit of confusion on the threads about which versions
you are actually running and/or talking about at any given moment.
Please try and be precise (e.g. in this instance you did not say which
distro you downloaded the source from, not what it''s precise package
version was, both of these are useful/critical information).

I unpacked 4.1.0-3ubuntu4, which appears to be current in Oneiric (and
looks a lot like the Debian Sid package), the only potentially
interesting patch is
debian/patches/tools-firmware-etherboot-packaged.diff which switches
from the ipxe in the Xen tree to the packaged one from /usr/lib/ipxe.

Both Ubuntu Oneiric and Debian Sid appear to contain ipxe 1.0.0
+git-1.293e34-2 whereas the Xen tree embeds v1.0.0 itself. Could be
worth investigating.

Ian.


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

xen-4.0.1/debian/patches  is a typo
xen-4.1.0/debian/patches should be

Boris

--- On Wed, 7/20/11, Ian Campbell <Ian.Campbell@citrix.com> wrote:

From: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric
Ocelot) (HVM DomUs crash)
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Keir Fraser"
<keir@xen.org>, "Konrad Rzeszutek Wilk"
<konrad.wilk@oracle.com>, "Stefano Stabellini"
<Stefano.Stabellini@eu.citrix.com>
Date: Wednesday, July 20, 2011, 4:19 AM

On Tue, 2011-07-19 at 20:01 +0100, Boris Derzhavets
wrote:
> I downloaded and installed  source . Went to
> xen-4.0.1/debian/patches.
But Oneiric Ocelot contains Xen 4.1.1 (according to
http://packages.ubuntu.com/oneiric/kernel/) and not xen-4.0.1. AFAICT
there is quite a bit of confusion on the threads about which versions
you are actually running and/or talking about at any given moment.
Please try and be precise (e.g. in this instance you did not say which
distro you downloaded the source from, not what it''s precise package
version was, both of these are useful/critical information).

I unpacked 4.1.0-3ubuntu4, which appears to be current in Oneiric (and
looks a lot like the Debian Sid package), the only potentially
interesting patch is
debian/patches/tools-firmware-etherboot-packaged.diff which switches
from the ipxe in the Xen tree to the packaged one from /usr/lib/ipxe.

Both Ubuntu Oneiric and Debian Sid appear to contain ipxe 1.0.0
+git-1.293e34-2 whereas the Xen tree embeds v1.0.0 itself. Could be
worth investigating.

Ian.


_______________________________________________
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

On Wed, 20 Jul 2011, Boris Derzhavets wrote:
> xen-4.0.1/debian/patches  is a typo
> xen-4.1.0/debian/patches should be
it is not something in the patchqueue: it is a gcc problem.
It works when compiled with gcc 4.5 but it does not work when compiled
with gcc 4.6. Gcc 4.6 is the default on Ubuntu Oneiric Ocelot.
--8323329-1961366966-1311158535=:12963
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--8323329-1961366966-1311158535=:12963--

That''s why it happens on F15 

[boris@fedora15 ~]$ gcc --version
gcc (GCC) 4.6.0 20110530 (Red Hat 4.6.0-9)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Boris.


--- On Wed, 7/20/11, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric
Ocelot) (HVM DomUs crash)
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Keir Fraser"
<keir@xen.org>, "Tim Deegan" <Tim.Deegan@citrix.com>,
"Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>,
"Wilk" <konrad.wilk@oracle.com>, "Ian Campbell"
<Ian.Campbell@eu.citrix.com>, Konrad@yahoo.com
Date: Wednesday, July 20, 2011, 6:45 AM

On Wed, 20 Jul 2011, Boris Derzhavets wrote:
> xen-4.0.1/debian/patches  is a typo
> xen-4.1.0/debian/patches should be
it is not something in the patchqueue: it is a gcc problem.
It works when compiled with gcc 4.5 but it does not work when compiled
with gcc 4.6. Gcc 4.6 is the default on Ubuntu Oneiric Ocelot.
-----Inline Attachment Follows-----

_______________________________________________
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

Sorry, one more question. Xen 4.2 Unstable appears to be tolerant to Gcc 4.6.
Why ?

Boris.

--- On Wed, 7/20/11, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric
Ocelot) (HVM DomUs crash)
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Keir Fraser" <keir@xen.org>, "Konrad Rzeszutek Wilk"
<konrad.wilk@oracle.com>, "Stefano Stabellini"
<Stefano.Stabellini@eu.citrix.com>, "Tim Deegan"
<Tim.Deegan@citrix.com>
Date: Wednesday, July 20, 2011, 6:45 AM

On Wed, 20 Jul 2011, Boris Derzhavets wrote:
> xen-4.0.1/debian/patches  is a typo
> xen-4.1.0/debian/patches should be
it is not something in the patchqueue: it is a gcc problem.
It works when compiled with gcc 4.5 but it does not work when compiled
with gcc 4.6. Gcc 4.6 is the default on Ubuntu Oneiric Ocelot.

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

On 20.07.2011 12:45, Stefano Stabellini wrote:
> On Wed, 20 Jul 2011, Boris Derzhavets wrote:
>> xen-4.0.1/debian/patches  is a typo
>> xen-4.1.0/debian/patches should be
> 
> it is not something in the patchqueue: it is a gcc problem.
> It works when compiled with gcc 4.5 but it does not work when compiled
> with gcc 4.6. Gcc 4.6 is the default on Ubuntu Oneiric Ocelot.
> 
It does not give away too much more, but compiling the firmware dir with gcc-4.6
and "make debug=y" (which also changes -O2 into -O1) produces a
working
hvmloader, too
> 
> 
> _______________________________________________
> 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

On 20/07/2011 13:44, "Stefan Bader" <stefan.bader@canonical.com>
wrote:
> On 20.07.2011 12:45, Stefano Stabellini wrote:
>> On Wed, 20 Jul 2011, Boris Derzhavets wrote:
>>> xen-4.0.1/debian/patches  is a typo
>>> xen-4.1.0/debian/patches should be
>> 
>> it is not something in the patchqueue: it is a gcc problem.
>> It works when compiled with gcc 4.5 but it does not work when compiled
>> with gcc 4.6. Gcc 4.6 is the default on Ubuntu Oneiric Ocelot.
>> 
> It does not give away too much more, but compiling the firmware dir with
> gcc-4.6
> and "make debug=y" (which also changes -O2 into -O1) produces a
working
> hvmloader, too
This bug is now fixed by xen-unstable:23730, xen-4.1-testing:23104, and
xen-4.0-testing:21523.

 -- Keir
>> 
>> 
>> _______________________________________________
>> 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

How long takes xen-4.1-testing:23104 to appear on the page

http://xenbits.xen.org/hg/xen-4.1-testing.hg/shortlog/

fow now 23102 is a maximum

Boris

--- On Wed, 7/20/11, Keir Fraser <keir.xen@gmail.com> wrote:

From: Keir Fraser <keir.xen@gmail.com>
Subject: Re: [Xen-devel] Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric
Ocelot) (HVM DomUs crash)
To: "Stefan Bader" <stefan.bader@canonical.com>, "Stefano
Stabellini" <stefano.stabellini@eu.citrix.com>
Cc: "Boris Derzhavets" <bderzhavets@yahoo.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Keir Fraser" <keir@xen.org>, "Tim Deegan"
<Tim.Deegan@citrix.com>, "Konrad Rzeszutek Wilk"
<konrad.wilk@oracle.com>, "Ian Campbell"
<Ian.Campbell@eu.citrix.com>, Konrad@rly45e.srv.mailcontrol.com
Date: Wednesday, July 20, 2011, 11:03 AM

On 20/07/2011 13:44, "Stefan Bader" <stefan.bader@canonical.com>
wrote:
> On 20.07.2011 12:45, Stefano Stabellini wrote:
>> On Wed, 20 Jul 2011, Boris Derzhavets wrote:
>>> xen-4.0.1/debian/patches  is a typo
>>> xen-4.1.0/debian/patches should be
>> 
>> it is not something in the patchqueue: it is a gcc problem.
>> It works when compiled with gcc 4.5 but it does not work when compiled
>> with gcc 4.6. Gcc 4.6 is the default on Ubuntu Oneiric Ocelot.
>> 
> It does not give away too much more, but compiling the firmware dir with
> gcc-4.6
> and "make debug=y" (which also changes -O2 into -O1) produces a
working
> hvmloader, too
This bug is now fixed by xen-unstable:23730, xen-4.1-testing:23104, and
xen-4.0-testing:21523.

 -- Keir
>> 
>> 
>> _______________________________________________
>> 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

On Wed, 2011-07-20 at 16:57 +0100, Boris Derzhavets
wrote:
> How long takes xen-4.1-testing:23104 to appear on the page
> 
> http://xenbits.xen.org/hg/xen-4.1-testing.hg/shortlog/
> 
> fow now 23102 is a maximum
> 
As long as it takes for the automated tests to get a pass. You can check
the staging (pre-test) tree instead at:
http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/

Ian.



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

hi all,

Just made a trace record file in a 8-core server with xentrace in xen 
4.0.1, however, problem happens in converting the record file:

[root@localhost szy_work]# cat ./rec.raw | xentrace_format ./formats > 
rec.txt
Traceback (most recent call last):
   File "/usr/bin/xentrace_format", line 192, in ?
     irq_measure[d1][''count''] += 1
IndexError: list index out of range

Seems the build-in xentrace_format in Xen 4.0.1 is problematic. I can 
convert the record file with xentrace_format from Xen 3.4.2...

Thanks,
Zhiyuan

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

Problem on Ubuntu 11.10 is fixed :-

https://launchpad.net/~bderzhavets/+archive/xen-4.1.1


ThanksBoris.


--- On Wed, 7/20/11, Keir Fraser <keir.xen@gmail.com> wrote:

From: Keir Fraser <keir.xen@gmail.com>
Subject: Re: [Xen-devel] Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric
Ocelot) (HVM DomUs crash)
To: "Stefan Bader" <stefan.bader@canonical.com>, "Stefano
Stabellini" <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Keir Fraser"
<keir@xen.org>, "Tim Deegan" <Tim.Deegan@citrix.com>,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, "Ian
Campbell" <Ian.Campbell@eu.citrix.com>, "Boris Derzhavets"
<bderzhavets@yahoo.com>, Konrad@rly45e.srv.mailcontrol.com
Date: Wednesday, July 20, 2011, 11:03 AM

On 20/07/2011 13:44, "Stefan Bader" <stefan.bader@canonical.com>
wrote:
> On 20.07.2011 12:45, Stefano Stabellini wrote:
>> On Wed, 20 Jul 2011, Boris Derzhavets wrote:
>>> xen-4.0.1/debian/patches  is a typo
>>> xen-4.1.0/debian/patches should be
>> 
>> it is not something in the patchqueue: it is a gcc problem.
>> It works when compiled with gcc 4.5 but it does not work when compiled
>> with gcc 4.6. Gcc 4.6 is the default on Ubuntu Oneiric Ocelot.
>> 
> It does not give away too much more, but compiling the firmware dir with
> gcc-4.6
> and "make debug=y" (which also changes -O2 into -O1) produces a
working
> hvmloader, too
This bug is now fixed by xen-unstable:23730, xen-4.1-testing:23104, and
xen-4.0-testing:21523.

 -- Keir
>> 
>> 
>> _______________________________________________
>> 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

Build  error :-

Calculated checksum:  0x44  Setting checksum.
ls -l VGABIOS-lgpl-latest.cirrus.debug.bin
-rw-rw-r-- 1 buildd buildd 35840 Jul 28 17:27
VGABIOS-lgpl-latest.cirrus.debug.bin
make[8]: Leaving directory
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/vgabios''
make[7]: Leaving directory
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
make[7]: Entering directory
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
/usr/bin/make -C etherboot all
make[8]: Entering directory
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/etherboot''
make[8]: *** No rule to make target `/usr/lib/ipxe/rtl8139.rom'', needed
by `eb-roms.h''.  Stop.
make[8]: Leaving directory
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/etherboot''
make[7]: *** [subdir-all-etherboot] Error 2
make[7]: Leaving directory
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
make[6]: *** [subdirs-all] Error 2
make[6]: Leaving directory
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
make[5]: *** [all] Error 2
make[5]: Leaving directory
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
make[4]: *** [subdir-all-firmware] Error 2
make[4]: Leaving directory
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools''
make[3]: *** [subdirs-all] Error 2
make[3]: Leaving directory
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools''
make[2]: *** [debian/stamps/build-utils_amd64] Error 2
make[2]: Leaving directory `/build/buildd/xen-4.1.1''
make[1]: *** [build_amd64_real] Error 2
make[1]: Leaving directory `/build/buildd/xen-4.1.1''
make: *** [debian/stamps/build-base] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

Boris.



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

On 28/07/2011 18:58, "Boris Derzhavets" <bderzhavets@yahoo.com>
wrote:
> Build  error :-
The stated changesets don''t touch tools/firmware. They''re
unlikely to be
causing your build failure.

 -- Keir
> Calculated checksum:  0x44  Setting checksum.
> ls -l VGABIOS-lgpl-latest.cirrus.debug.bin
> -rw-rw-r-- 1 buildd buildd 35840 Jul 28 17:27
> VGABIOS-lgpl-latest.cirrus.debug.bin
> make[8]: Leaving directory
> 
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/vgabios>
''
> make[7]: Leaving directory
>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
> make[7]: Entering directory
>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
> /usr/bin/make -C etherboot all
> make[8]: Entering directory
>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/etherbo
> ot''
> make[8]: *** No rule to make target `/usr/lib/ipxe/rtl8139.rom'',
needed by
> `eb-roms.h''.  Stop.
> make[8]: Leaving directory
>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/etherbo
> ot''
> make[7]: *** [subdir-all-etherboot] Error 2
> make[7]: Leaving directory
>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
> make[6]: *** [subdirs-all] Error 2
> make[6]: Leaving directory
>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
> make[5]: *** [all] Error 2
> make[5]: Leaving directory
>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
> make[4]: *** [subdir-all-firmware] Error 2
> make[4]: Leaving directory
> `/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools''
> make[3]: *** [subdirs-all] Error 2
> make[3]: Leaving directory
> `/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools''
> make[2]: *** [debian/stamps/build-utils_amd64] Error 2
> make[2]: Leaving directory `/build/buildd/xen-4.1.1''
> make[1]: *** [build_amd64_real] Error 2
> make[1]: Leaving directory `/build/buildd/xen-4.1.1''
> make: *** [debian/stamps/build-base] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> 
> Boris.
> 
> 


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

Only 3 CSs backported :-
changeset 23104  - No problems . HVM fixNext step =>  23088 and 23089 .  This
step causes build failure.

Boris.

--- On Thu, 7/28/11, Keir Fraser <keir.xen@gmail.com> wrote:

From: Keir Fraser <keir.xen@gmail.com>
Subject: [Xen-devel] Re: Attempt to backport changeset-23088, changeset-23089 to
Xen 4.1.1
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Date: Thursday, July 28, 2011, 3:04 PM

On 28/07/2011 18:58, "Boris Derzhavets" <bderzhavets@yahoo.com>
wrote:
> Build  error :-
The stated changesets don''t touch tools/firmware. They''re
unlikely to be
causing your build failure.

 -- Keir
> Calculated checksum:  0x44  Setting checksum.
> ls -l VGABIOS-lgpl-latest.cirrus.debug.bin
> -rw-rw-r-- 1 buildd buildd 35840 Jul 28 17:27
> VGABIOS-lgpl-latest.cirrus.debug.bin
> make[8]: Leaving directory
> 
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/vgabios>
''
> make[7]: Leaving directory
>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
> make[7]: Entering directory
>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
> /usr/bin/make -C etherboot all
> make[8]: Entering directory
>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/etherbo
> ot''
> make[8]: *** No rule to make target `/usr/lib/ipxe/rtl8139.rom'',
needed by
> `eb-roms.h''.  Stop.
> make[8]: Leaving directory
>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/etherbo
> ot''
> make[7]: *** [subdir-all-etherboot] Error 2
> make[7]: Leaving directory
>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
> make[6]: *** [subdirs-all] Error 2
> make[6]: Leaving directory
>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
> make[5]: *** [all] Error 2
> make[5]: Leaving directory
>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
> make[4]: *** [subdir-all-firmware] Error 2
> make[4]: Leaving directory
> `/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools''
> make[3]: *** [subdirs-all] Error 2
> make[3]: Leaving directory
> `/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools''
> make[2]: *** [debian/stamps/build-utils_amd64] Error 2
> make[2]: Leaving directory `/build/buildd/xen-4.1.1''
> make[1]: *** [build_amd64_real] Error 2
> make[1]: Leaving directory `/build/buildd/xen-4.1.1''
> make: *** [debian/stamps/build-base] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> 
> Boris.
> 
> 


_______________________________________________
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

On 28/07/2011 20:41, "Boris Derzhavets" <bderzhavets@yahoo.com>
wrote:
> Only 3 CSs backported :-
> changeset 23104  - No problems . HVM fix
> Next step =>  23088 and 23089 .  This step causes build failure.
Is that 23089:8ec7808f9c23 and 23088:49728fe8dd6a? There is zero chance of
either of those being the cause of a build failure under tools/firmware.

 -- Keir
> Boris.
> 
> --- On Thu, 7/28/11, Keir Fraser <keir.xen@gmail.com> wrote:
>> 
>> From: Keir Fraser <keir.xen@gmail.com>
>> Subject: [Xen-devel] Re: Attempt to backport changeset-23088,
changeset-23089
>> to Xen 4.1.1
>> To: "Boris Derzhavets" <bderzhavets@yahoo.com>
>> Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
>> "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Konrad
>> Rzeszutek Wilk" <konrad.wilk@oracle.com>
>> Date: Thursday, July 28, 2011, 3:04 PM
>> 
>> On 28/07/2011 18:58, "Boris Derzhavets"
<bderzhavets@yahoo.com
>> </mc/compose?to=bderzhavets@yahoo.com> > wrote:
>> 
>>> Build  error :-
>> 
>> The stated changesets don''t touch tools/firmware.
They''re unlikely to be
>> causing your build failure.
>> 
>>  -- Keir
>> 
>>> Calculated checksum:  0x44  Setting checksum.
>>> ls -l VGABIOS-lgpl-latest.cirrus.debug.bin
>>> -rw-rw-r-- 1 buildd buildd 35840 Jul 28 17:27
>>> VGABIOS-lgpl-latest.cirrus.debug.bin
>>> make[8]: Leaving directory
>>> 
>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/vgabio
>> s>
>> ''
>>> make[7]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>> make[7]: Entering directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>> /usr/bin/make -C etherboot all
>>> make[8]: Entering directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/ether
>>> bo
>>> ot''
>>> make[8]: *** No rule to make target
`/usr/lib/ipxe/rtl8139.rom'', needed by
>>> `eb-roms.h''.  Stop.
>>> make[8]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/ether
>>> bo
>>> ot''
>>> make[7]: *** [subdir-all-etherboot] Error 2
>>> make[7]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>> make[6]: *** [subdirs-all] Error 2
>>> make[6]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>> make[5]: *** [all] Error 2
>>> make[5]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>> make[4]: *** [subdir-all-firmware] Error 2
>>> make[4]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools''
>>> make[3]: *** [subdirs-all] Error 2
>>> make[3]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools''
>>> make[2]: *** [debian/stamps/build-utils_amd64] Error 2
>>> make[2]: Leaving directory `/build/buildd/xen-4.1.1''
>>> make[1]: *** [build_amd64_real] Error 2
>>> make[1]: Leaving directory `/build/buildd/xen-4.1.1''
>>> make: *** [debian/stamps/build-base] Error 2
>>> dpkg-buildpackage: error: debian/rules build gave error exit status
2
>>> 
>>> Boris.
>>> 
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
</mc/compose?to=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

>Is that 23089:8ec7808f9c23 and 23088:49728fe8dd6a? There is zero chance of
>  either of those being the cause of a build failure under tools/firmware
It was  23089:0300d7f10d42  and  23088:37ba0319e2cf  from
http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/.   Build was on Ubuntu
11.10 .  There was notice
of Ian Campbell regarding Ubuntu''s  patching ipxe  on
xen-4.1.0/debian/patches .   He wrote that it was worth to look into that. I
will try to find his message.

Boris.


--- On Thu, 7/28/11, Keir Fraser <keir.xen@gmail.com> wrote:

From: Keir Fraser <keir.xen@gmail.com>
Subject: Re: [Xen-devel] Re: Attempt to backport changeset-23088,
changeset-23089 to Xen 4.1.1
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Date: Thursday, July 28, 2011, 3:53 PM

On 28/07/2011 20:41, "Boris Derzhavets" <bderzhavets@yahoo.com>
wrote:
> Only 3 CSs backported :-
> changeset 23104  - No problems . HVM fix
> Next step =>  23088 and 23089 .  This step causes build failure.
Is that 23089:8ec7808f9c23 and 23088:49728fe8dd6a? There is zero chance of
either of those being the cause of a build failure under tools/firmware.

 -- Keir
> Boris.
> 
> --- On Thu, 7/28/11, Keir Fraser <keir.xen@gmail.com> wrote:
>> 
>> From: Keir Fraser <keir.xen@gmail.com>
>> Subject: [Xen-devel] Re: Attempt to backport changeset-23088,
changeset-23089
>> to Xen 4.1.1
>> To: "Boris Derzhavets" <bderzhavets@yahoo.com>
>> Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
>> "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Konrad
>> Rzeszutek Wilk" <konrad.wilk@oracle.com>
>> Date: Thursday, July 28, 2011, 3:04 PM
>> 
>> On 28/07/2011 18:58, "Boris Derzhavets"
<bderzhavets@yahoo.com
>> </mc/compose?to=bderzhavets@yahoo.com> > wrote:
>> 
>>> Build  error :-
>> 
>> The stated changesets don''t touch tools/firmware.
They''re unlikely to be
>> causing your build failure.
>> 
>>  -- Keir
>> 
>>> Calculated checksum:  0x44  Setting checksum.
>>> ls -l VGABIOS-lgpl-latest.cirrus.debug.bin
>>> -rw-rw-r-- 1 buildd buildd 35840 Jul 28 17:27
>>> VGABIOS-lgpl-latest.cirrus.debug.bin
>>> make[8]: Leaving directory
>>> 
>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/vgabio
>> s>
>> ''
>>> make[7]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>> make[7]: Entering directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>> /usr/bin/make -C etherboot all
>>> make[8]: Entering directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/ether
>>> bo
>>> ot''
>>> make[8]: *** No rule to make target
`/usr/lib/ipxe/rtl8139.rom'', needed by
>>> `eb-roms.h''.  Stop.
>>> make[8]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/ether
>>> bo
>>> ot''
>>> make[7]: *** [subdir-all-etherboot] Error 2
>>> make[7]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>> make[6]: *** [subdirs-all] Error 2
>>> make[6]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>> make[5]: *** [all] Error 2
>>> make[5]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>> make[4]: *** [subdir-all-firmware] Error 2
>>> make[4]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools''
>>> make[3]: *** [subdirs-all] Error 2
>>> make[3]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools''
>>> make[2]: *** [debian/stamps/build-utils_amd64] Error 2
>>> make[2]: Leaving directory `/build/buildd/xen-4.1.1''
>>> make[1]: *** [build_amd64_real] Error 2
>>> make[1]: Leaving directory `/build/buildd/xen-4.1.1''
>>> make: *** [debian/stamps/build-base] Error 2
>>> dpkg-buildpackage: error: debian/rules build gave error exit status
2
>>> 
>>> Boris.
>>> 
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
</mc/compose?to=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

******************************************
I found this notice of Ian Campbell 
******************************************

Re: [Xen-devel] Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot) (HVM
DomUs crash) Wednesday, July 20, 2011 4:19 AM
From: "Ian Campbell" <Ian.Campbell@citrix.com>
Add sender to Contacts 
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc:"Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Keir Fraser" <keir@xen.org>, "Konrad Rzeszutek Wilk"
<konrad.wilk@oracle.com>


I unpacked 4.1.0-3ubuntu4, which appears to be current in Oneiric (and
looks a lot like the Debian Sid package), the only potentially
interesting patch is
debian/patches/tools-firmware-etherboot-packaged.diff which switches
from the ipxe in the Xen tree to the packaged one from /usr/lib/ipxe.

Both Ubuntu Oneiric and Debian Sid appear to contain ipxe 1.0.0
+git-1.293e34-2 whereas the Xen tree embeds v1.0.0 itself. Could be
worth investigating.

Ian.

-----------------------------------------------------------------------------------------------------------------------------

Same file is in  XEN 4.1.1 Ubuntu Oneiric packaging :

boris@boris-System-P5Q3:~/CHUCK-STUFF/xen-4.1.1/debian/patches$ ls -l
tools-firmware-etherboot-packaged.diff

-rw-r--r-- 1 boris boris 1464 2011-07-28 21:17
tools-firmware-etherboot-packaged.diff


Boris.
--- On Thu, 7/28/11, Keir Fraser <keir.xen@gmail.com> wrote:

From: Keir Fraser <keir.xen@gmail.com>
Subject: Re: [Xen-devel] Re: Attempt to backport changeset-23088,
changeset-23089 to Xen 4.1.1
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Date: Thursday, July 28, 2011, 3:53 PM

On 28/07/2011 20:41, "Boris Derzhavets" <bderzhavets@yahoo.com>
wrote:
> Only 3 CSs backported :-
> changeset 23104  - No problems . HVM fix
> Next step =>  23088 and 23089 .  This step causes build failure.
Is that 23089:8ec7808f9c23 and 23088:49728fe8dd6a? There is zero chance of
either of those being the cause of a build failure under tools/firmware.

 -- Keir
> Boris.
> 
> --- On Thu, 7/28/11, Keir Fraser <keir.xen@gmail.com> wrote:
>> 
>> From: Keir Fraser <keir.xen@gmail.com>
>> Subject: [Xen-devel] Re: Attempt to backport changeset-23088,
changeset-23089
>> to Xen 4.1.1
>> To: "Boris Derzhavets" <bderzhavets@yahoo.com>
>> Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
>> "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Konrad
>> Rzeszutek Wilk" <konrad.wilk@oracle.com>
>> Date: Thursday, July 28, 2011, 3:04 PM
>> 
>> On 28/07/2011 18:58, "Boris Derzhavets"
<bderzhavets@yahoo.com
>> </mc/compose?to=bderzhavets@yahoo.com> > wrote:
>> 
>>> Build  error :-
>> 
>> The stated changesets don''t touch tools/firmware.
They''re unlikely to be
>> causing your build failure.
>> 
>>  -- Keir
>> 
>>> Calculated checksum:  0x44  Setting checksum.
>>> ls -l VGABIOS-lgpl-latest.cirrus.debug.bin
>>> -rw-rw-r-- 1 buildd buildd 35840 Jul 28 17:27
>>> VGABIOS-lgpl-latest.cirrus.debug.bin
>>> make[8]: Leaving directory
>>> 
>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/vgabio
>> s>
>> ''
>>> make[7]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>> make[7]: Entering directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>> /usr/bin/make -C etherboot all
>>> make[8]: Entering directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/ether
>>> bo
>>> ot''
>>> make[8]: *** No rule to make target
`/usr/lib/ipxe/rtl8139.rom'', needed by
>>> `eb-roms.h''.  Stop.
>>> make[8]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/ether
>>> bo
>>> ot''
>>> make[7]: *** [subdir-all-etherboot] Error 2
>>> make[7]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>> make[6]: *** [subdirs-all] Error 2
>>> make[6]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>> make[5]: *** [all] Error 2
>>> make[5]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>> make[4]: *** [subdir-all-firmware] Error 2
>>> make[4]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools''
>>> make[3]: *** [subdirs-all] Error 2
>>> make[3]: Leaving directory
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools''
>>> make[2]: *** [debian/stamps/build-utils_amd64] Error 2
>>> make[2]: Leaving directory `/build/buildd/xen-4.1.1''
>>> make[1]: *** [build_amd64_real] Error 2
>>> make[1]: Leaving directory `/build/buildd/xen-4.1.1''
>>> make: *** [debian/stamps/build-base] Error 2
>>> dpkg-buildpackage: error: debian/rules build gave error exit status
2
>>> 
>>> Boris.
>>> 
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
</mc/compose?to=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

On 28/07/2011 22:50, "Boris Derzhavets" <bderzhavets@yahoo.com>
wrote:
>> Is that 23089:8ec7808f9c23 and 23088:49728fe8dd6a? There is zero chance
of
>>  either of those being the cause of a build failure under
tools/firmware
> 
> It was  23089:0300d7f10d42  and  23088:37ba0319e2cf  from
> http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/.
Ah okay, well neither of those would break the tools/fimrware build either.
>  Build was on Ubuntu
> 11.10 .  There was notice
> of Ian Campbell regarding Ubuntu''s  patching ipxe  on
xen-4.1.0/debian/patches
> .   He wrote that it was worth to look into that. I will try to find his
> message.
Yes, it seems more likely to be an Ubuntu patch that has broken your build.

 -- Keir
> Boris.
> 
> 
> --- On Thu, 7/28/11, Keir Fraser <keir.xen@gmail.com> wrote:
>> 
>> From: Keir Fraser <keir.xen@gmail.com>
>> Subject: Re: [Xen-devel] Re: Attempt to backport changeset-23088,
>> changeset-23089 to Xen 4.1.1
>> To: "Boris Derzhavets" <bderzhavets@yahoo.com>
>> Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
>> "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Konrad
>> Rzeszutek Wilk" <konrad.wilk@oracle.com>
>> Date: Thursday, July 28, 2011, 3:53 PM
>> 
>> On 28/07/2011 20:41, "Boris Derzhavets"
<bderzhavets@yahoo.com
>> </mc/compose?to=bderzhavets@yahoo.com> > wrote:
>> 
>>> Only 3 CSs backported :-
>>> changeset 23104  - No problems . HVM fix
>>> Next step =>  23088 and 23089 .  This step causes build failure.
>> 
>> Is that 23089:8ec7808f9c23 and 23088:49728fe8dd6a? There is zero chance
of
>> either of those being the cause of a build failure under
tools/firmware.
>> 
>>  -- Keir
>> 
>>> Boris.
>>> 
>>> --- On Thu, 7/28/11, Keir Fraser <keir.xen@gmail.com
>>> </mc/compose?to=keir.xen@gmail.com> > wrote:
>>>> 
>>>> From: Keir Fraser <keir.xen@gmail.com
</mc/compose?to=keir.xen@gmail.com> >
>>>> Subject: [Xen-devel] Re: Attempt to backport changeset-23088,
>>>> changeset-23089
>>>> to Xen 4.1.1
>>>> To: "Boris Derzhavets" <bderzhavets@yahoo.com
>>>> </mc/compose?to=bderzhavets@yahoo.com> >
>>>> Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com
>>>> </mc/compose?to=Ian.Campbell@eu.citrix.com> >,
>>>> "xen-devel@lists.xensource.com
>>>> </mc/compose?to=xen-devel@lists.xensource.com> "
>>>> <xen-devel@lists.xensource.com
>>>> </mc/compose?to=xen-devel@lists.xensource.com> >,
"Konrad
>>>> Rzeszutek Wilk" <konrad.wilk@oracle.com
>>>> </mc/compose?to=konrad.wilk@oracle.com> >
>>>> Date: Thursday, July 28, 2011, 3:04 PM
>>>> 
>>>> On 28/07/2011 18:58, "Boris Derzhavets"
<bderzhavets@yahoo.com
>>>> </mc/compose?to=bderzhavets@yahoo.com>
>>>> </mc/compose?to=bderzhavets@yahoo.com
>>>> </mc/compose?to=bderzhavets@yahoo.com> > > wrote:
>>>> 
>>>>> Build  error :-
>>>> 
>>>> The stated changesets don''t touch tools/firmware.
They''re unlikely to be
>>>> causing your build failure.
>>>> 
>>>>  -- Keir
>>>> 
>>>>> Calculated checksum:  0x44  Setting checksum.
>>>>> ls -l VGABIOS-lgpl-latest.cirrus.debug.bin
>>>>> -rw-rw-r-- 1 buildd buildd 35840 Jul 28 17:27
>>>>> VGABIOS-lgpl-latest.cirrus.debug.bin
>>>>> make[8]: Leaving directory
>>>>> 
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/vgab
>>>> io
>>>> s>
>>>> ''
>>>>> make[7]: Leaving directory
>>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>>>> make[7]: Entering directory
>>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>>>> /usr/bin/make -C etherboot all
>>>>> make[8]: Entering directory
>>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/eth
>>>>> er
>>>>> bo
>>>>> ot''
>>>>> make[8]: *** No rule to make target
`/usr/lib/ipxe/rtl8139.rom'', needed by
>>>>> `eb-roms.h''.  Stop.
>>>>> make[8]: Leaving directory
>>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/eth
>>>>> er
>>>>> bo
>>>>> ot''
>>>>> make[7]: *** [subdir-all-etherboot] Error 2
>>>>> make[7]: Leaving directory
>>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>>>> make[6]: *** [subdirs-all] Error 2
>>>>> make[6]: Leaving directory
>>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>>>> make[5]: *** [all] Error 2
>>>>> make[5]: Leaving directory
>>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>>>> make[4]: *** [subdir-all-firmware] Error 2
>>>>> make[4]: Leaving directory
>>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools''
>>>>> make[3]: *** [subdirs-all] Error 2
>>>>> make[3]: Leaving directory
>>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools''
>>>>> make[2]: *** [debian/stamps/build-utils_amd64] Error 2
>>>>> make[2]: Leaving directory
`/build/buildd/xen-4.1.1''
>>>>> make[1]: *** [build_amd64_real] Error 2
>>>>> make[1]: Leaving directory
`/build/buildd/xen-4.1.1''
>>>>> make: *** [debian/stamps/build-base] Error 2
>>>>> dpkg-buildpackage: error: debian/rules build gave error
exit status 2
>>>>> 
>>>>> Boris.
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> </mc/compose?to=Xen-devel@lists.xensource.com>
>>>> </mc/compose?to=Xen-devel@lists.xensource.com
>>>> </mc/compose?to=Xen-devel@lists.xensource.com> >
>>>> http://lists.xensource.com/xen-devel
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
</mc/compose?to=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

On 29.07.2011 00:02, Boris Derzhavets wrote:
> ******************************************
> I found this notice of Ian Campbell 
> ******************************************
> 
> Re: [Xen-devel] Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot)
(HVM DomUs crash) Wednesday, July 20, 2011 4:19 AM
> From: "Ian Campbell" <Ian.Campbell@citrix.com>
> Add sender to Contacts 
> To: "Boris Derzhavets" <bderzhavets@yahoo.com>
> Cc:"Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Keir Fraser" <keir@xen.org>, "Konrad Rzeszutek Wilk"
<konrad.wilk@oracle.com>
> 
> 
> I unpacked 4.1.0-3ubuntu4, which appears to be current in Oneiric (and
> looks a lot like the Debian Sid package), the only potentially
> interesting patch is
> debian/patches/tools-firmware-etherboot-packaged.diff which switches
> from the ipxe in the Xen tree to the packaged one from /usr/lib/ipxe.
> 
Just to note that there is a newer (4.1.1) package pending to be build but got
stuck because of dependency problems after having it promoted from universe to
main.

-Stefan
> Both Ubuntu Oneiric and Debian Sid appear to contain ipxe 1.0.0
> +git-1.293e34-2 whereas the Xen tree embeds v1.0.0 itself. Could be
> worth investigating.
> 
> Ian.
> 
>
-----------------------------------------------------------------------------------------------------------------------------
> 
> Same file is in  XEN 4.1.1 Ubuntu Oneiric packaging :
> 
> boris@boris-System-P5Q3:~/CHUCK-STUFF/xen-4.1.1/debian/patches$ ls -l
tools-firmware-etherboot-packaged.diff
> 
> -rw-r--r-- 1 boris boris 1464 2011-07-28 21:17
tools-firmware-etherboot-packaged.diff
> 
> 
> Boris.
> --- On Thu, 7/28/11, Keir Fraser <keir.xen@gmail.com> wrote:
> 
> From: Keir Fraser <keir.xen@gmail.com>
> Subject: Re: [Xen-devel] Re: Attempt to backport changeset-23088,
changeset-23089 to Xen 4.1.1
> To: "Boris Derzhavets" <bderzhavets@yahoo.com>
> Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
> Date: Thursday, July 28, 2011, 3:53 PM
> 
> On 28/07/2011 20:41, "Boris Derzhavets"
<bderzhavets@yahoo.com> wrote:
> 
>> Only 3 CSs backported :-
>> changeset 23104  - No problems . HVM fix
>> Next step =>  23088 and 23089 .  This step causes build failure.
> 
> Is that 23089:8ec7808f9c23 and 23088:49728fe8dd6a? There is zero chance of
> either of those being the cause of a build failure under tools/firmware.
> 
>  -- Keir
> 
>> Boris.
>>
>> --- On Thu, 7/28/11, Keir Fraser <keir.xen@gmail.com> wrote:
>>>
>>> From: Keir Fraser <keir.xen@gmail.com>
>>> Subject: [Xen-devel] Re: Attempt to backport changeset-23088,
changeset-23089
>>> to Xen 4.1.1
>>> To: "Boris Derzhavets" <bderzhavets@yahoo.com>
>>> Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
>>> "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Konrad
>>> Rzeszutek Wilk" <konrad.wilk@oracle.com>
>>> Date: Thursday, July 28, 2011, 3:04 PM
>>>
>>> On 28/07/2011 18:58, "Boris Derzhavets"
<bderzhavets@yahoo.com
>>> </mc/compose?to=bderzhavets@yahoo.com> > wrote:
>>>
>>>> Build  error :-
>>>
>>> The stated changesets don''t touch tools/firmware.
They''re unlikely to be
>>> causing your build failure.
>>>
>>>   -- Keir
>>>
>>>> Calculated checksum:  0x44  Setting checksum.
>>>> ls -l VGABIOS-lgpl-latest.cirrus.debug.bin
>>>> -rw-rw-r-- 1 buildd buildd 35840 Jul 28 17:27
>>>> VGABIOS-lgpl-latest.cirrus.debug.bin
>>>> make[8]: Leaving directory
>>>>
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/vgabio
>>> s>
>>> ''
>>>> make[7]: Leaving directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>>> make[7]: Entering directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>>> /usr/bin/make -C etherboot all
>>>> make[8]: Entering directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/ether
>>>> bo
>>>> ot''
>>>> make[8]: *** No rule to make target
`/usr/lib/ipxe/rtl8139.rom'', needed by
>>>> `eb-roms.h''.  Stop.
>>>> make[8]: Leaving directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/ether
>>>> bo
>>>> ot''
>>>> make[7]: *** [subdir-all-etherboot] Error 2
>>>> make[7]: Leaving directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>>> make[6]: *** [subdirs-all] Error 2
>>>> make[6]: Leaving directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>>> make[5]: *** [all] Error 2
>>>> make[5]: Leaving directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>>> make[4]: *** [subdir-all-firmware] Error 2
>>>> make[4]: Leaving directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools''
>>>> make[3]: *** [subdirs-all] Error 2
>>>> make[3]: Leaving directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools''
>>>> make[2]: *** [debian/stamps/build-utils_amd64] Error 2
>>>> make[2]: Leaving directory `/build/buildd/xen-4.1.1''
>>>> make[1]: *** [build_amd64_real] Error 2
>>>> make[1]: Leaving directory `/build/buildd/xen-4.1.1''
>>>> make: *** [debian/stamps/build-base] Error 2
>>>> dpkg-buildpackage: error: debian/rules build gave error exit
status 2
>>>>
>>>> Boris.
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
</mc/compose?to=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

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

I understand. That is a reason why build  with just one additional
cs-23104.patch  :-


https://launchpadlibrarian.net/76060850/buildlog_ubuntu-oneiric-amd64.xen_4.1.1-1ubuntu4_BUILDING.txt.gz


cannot be reproduced any longer, giving the same error as was already submitted.


Boris.

--- On Fri, 7/29/11, Stefan Bader <stefan.bader@canonical.com> wrote:

From: Stefan Bader <stefan.bader@canonical.com>
Subject: Re: [Xen-devel] Re: Attempt to backport changeset-23088,
changeset-23089 to Xen 4.1.1-  Notice of Ian Campbell
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "Keir Fraser" <keir.xen@gmail.com>, "Ian Campbell"
<Ian.Campbell@eu.citrix.com>, "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Konrad Rzeszutek Wilk"
<konrad.wilk@oracle.com>
Date: Friday, July 29, 2011, 3:08 AM

On 29.07.2011 00:02, Boris Derzhavets wrote:
> ******************************************
> I found this notice of Ian Campbell 
> ******************************************
> 
> Re: [Xen-devel] Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot)
(HVM DomUs crash) Wednesday, July 20, 2011 4:19 AM
> From: "Ian Campbell" <Ian.Campbell@citrix.com>
> Add sender to Contacts 
> To: "Boris Derzhavets" <bderzhavets@yahoo.com>
> Cc:"Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Keir Fraser" <keir@xen.org>, "Konrad Rzeszutek Wilk"
<konrad.wilk@oracle.com>
> 
> 
> I unpacked 4.1.0-3ubuntu4, which appears to be current in Oneiric (and
> looks a lot like the Debian Sid package), the only potentially
> interesting patch is
> debian/patches/tools-firmware-etherboot-packaged.diff which switches
> from the ipxe in the Xen tree to the packaged one from /usr/lib/ipxe.
> 
Just to note that there is a newer (4.1.1) package pending to be build but got
stuck because of dependency problems after having it promoted from universe to
main.

-Stefan
> Both Ubuntu Oneiric and Debian Sid appear to contain ipxe 1.0.0
> +git-1.293e34-2 whereas the Xen tree embeds v1.0.0 itself. Could be
> worth investigating.
> 
> Ian.
> 
>
-----------------------------------------------------------------------------------------------------------------------------
> 
> Same file is in  XEN 4.1.1 Ubuntu Oneiric packaging :
> 
> boris@boris-System-P5Q3:~/CHUCK-STUFF/xen-4.1.1/debian/patches$ ls -l
tools-firmware-etherboot-packaged.diff
> 
> -rw-r--r-- 1 boris boris 1464 2011-07-28 21:17
tools-firmware-etherboot-packaged.diff
> 
> 
> Boris.
> --- On Thu, 7/28/11, Keir Fraser <keir.xen@gmail.com> wrote:
> 
> From: Keir Fraser <keir.xen@gmail.com>
> Subject: Re: [Xen-devel] Re: Attempt to backport changeset-23088,
changeset-23089 to Xen 4.1.1
> To: "Boris Derzhavets" <bderzhavets@yahoo.com>
> Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
> Date: Thursday, July 28, 2011, 3:53 PM
> 
> On 28/07/2011 20:41, "Boris Derzhavets"
<bderzhavets@yahoo.com> wrote:
> 
>> Only 3 CSs backported :-
>> changeset 23104  - No problems . HVM fix
>> Next step =>  23088 and 23089 .  This step causes build failure.
> 
> Is that 23089:8ec7808f9c23 and 23088:49728fe8dd6a? There is zero chance of
> either of those being the cause of a build failure under tools/firmware.
> 
>  -- Keir
> 
>> Boris.
>>
>> --- On Thu, 7/28/11, Keir Fraser <keir.xen@gmail.com> wrote:
>>>
>>> From: Keir Fraser <keir.xen@gmail.com>
>>> Subject: [Xen-devel] Re: Attempt to backport changeset-23088,
changeset-23089
>>> to Xen 4.1.1
>>> To: "Boris Derzhavets" <bderzhavets@yahoo.com>
>>> Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
>>> "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Konrad
>>> Rzeszutek Wilk" <konrad.wilk@oracle.com>
>>> Date: Thursday, July 28, 2011, 3:04 PM
>>>
>>> On 28/07/2011 18:58, "Boris Derzhavets"
<bderzhavets@yahoo.com
>>> </mc/compose?to=bderzhavets@yahoo.com> > wrote:
>>>
>>>> Build  error :-
>>>
>>> The stated changesets don''t touch tools/firmware.
They''re unlikely to be
>>> causing your build failure.
>>>
>>>   -- Keir
>>>
>>>> Calculated checksum:  0x44  Setting checksum.
>>>> ls -l VGABIOS-lgpl-latest.cirrus.debug.bin
>>>> -rw-rw-r-- 1 buildd buildd 35840 Jul 28 17:27
>>>> VGABIOS-lgpl-latest.cirrus.debug.bin
>>>> make[8]: Leaving directory
>>>>
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/vgabio
>>> s>
>>> ''
>>>> make[7]: Leaving directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>>> make[7]: Entering directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>>> /usr/bin/make -C etherboot all
>>>> make[8]: Entering directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/ether
>>>> bo
>>>> ot''
>>>> make[8]: *** No rule to make target
`/usr/lib/ipxe/rtl8139.rom'', needed by
>>>> `eb-roms.h''.  Stop.
>>>> make[8]: Leaving directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/ether
>>>> bo
>>>> ot''
>>>> make[7]: *** [subdir-all-etherboot] Error 2
>>>> make[7]: Leaving directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>>> make[6]: *** [subdirs-all] Error 2
>>>> make[6]: Leaving directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>>> make[5]: *** [all] Error 2
>>>> make[5]: Leaving directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>>> make[4]: *** [subdir-all-firmware] Error 2
>>>> make[4]: Leaving directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools''
>>>> make[3]: *** [subdirs-all] Error 2
>>>> make[3]: Leaving directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools''
>>>> make[2]: *** [debian/stamps/build-utils_amd64] Error 2
>>>> make[2]: Leaving directory `/build/buildd/xen-4.1.1''
>>>> make[1]: *** [build_amd64_real] Error 2
>>>> make[1]: Leaving directory `/build/buildd/xen-4.1.1''
>>>> make: *** [debian/stamps/build-base] Error 2
>>>> dpkg-buildpackage: error: debian/rules build gave error exit
status 2
>>>>
>>>> Boris.
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
</mc/compose?to=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


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

Actually, it can be reproduced : -

root@boris-P5Q-E:~# xl info
host                   : boris-P5Q-E
release                : 3.0.0-7-generic
version                : #8-Ubuntu SMP Fri Jul 22 20:26:22 UTC 2011
machine                : x86_64
nr_cpus                : 2
nr_nodes               : 1
cores_per_socket       : 2
threads_per_core       : 1
cpu_mhz                : 2999
hw_caps                :
bfebfbff:20100800:00000000:00000940:0008e3fd:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 8191
free_memory            : 1660
free_cpus              : 0
xen_major              : 4
xen_minor              : 1
xen_extra              : .1
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : placeholder
cc_compiler            : gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-5ubuntu2) 
cc_compile_by          : bderzhavets     <cc_compile_domain      : yahoo.com 
<cc_compile_date        : Fri Jul 29 13:46:54 UTC 2011
<xend_config_format     : 4


Boris
--- On Fri, 7/29/11, Boris Derzhavets <bderzhavets@yahoo.com> wrote:

From: Boris Derzhavets <bderzhavets@yahoo.com>
Subject: Re: [Xen-devel] Re: Attempt to backport changeset-23088,
changeset-23089 to Xen 4.1.1-  Notice of Ian Campbell
To: "Stefan Bader" <stefan.bader@canonical.com>
Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com>, "Keir
Fraser" <keir.xen@gmail.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Date: Friday, July 29, 2011, 5:30 AM

I understand. That is a reason why build  with just one additional
cs-23104.patch  :-


https://launchpadlibrarian.net/76060850/buildlog_ubuntu-oneiric-amd64.xen_4.1.1-1ubuntu4_BUILDING.txt.gz


cannot be reproduced any longer, giving the same error as was already submitted.


Boris.

--- On Fri, 7/29/11, Stefan Bader <stefan.bader@canonical.com> wrote:

From: Stefan Bader <stefan.bader@canonical.com>
Subject: Re: [Xen-devel] Re: Attempt to backport changeset-23088,
changeset-23089 to Xen 4.1.1-  Notice of Ian Campbell
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "Keir Fraser" <keir.xen@gmail.com>, "Ian Campbell"
<Ian.Campbell@eu.citrix.com>, "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Konrad Rzeszutek Wilk"
<konrad.wilk@oracle.com>
Date: Friday, July 29, 2011, 3:08 AM

On 29.07.2011 00:02, Boris Derzhavets wrote:
> ******************************************
> I found this notice of Ian Campbell 
> ******************************************
> 
> Re: [Xen-devel] Re:
 Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot) (HVM DomUs crash)
Wednesday, July 20, 2011 4:19 AM
> From: "Ian Campbell" <Ian.Campbell@citrix.com>
> Add sender to Contacts 
> To: "Boris Derzhavets" <bderzhavets@yahoo.com>
> Cc:"Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Keir Fraser" <keir@xen.org>, "Konrad Rzeszutek Wilk"
<konrad.wilk@oracle.com>
> 
> 
> I unpacked 4.1.0-3ubuntu4, which appears to be current in Oneiric (and
> looks a lot like the Debian Sid package), the only potentially
> interesting patch is
> debian/patches/tools-firmware-etherboot-packaged.diff which switches
> from the ipxe in the Xen tree to the packaged one from /usr/lib/ipxe.
> 
Just to note that there is a newer (4.1.1) package pending to be build but got
stuck because of dependency problems after having it promoted from universe to
main.

-Stefan
> Both Ubuntu Oneiric and Debian Sid appear to contain ipxe 1.0.0
> +git-1.293e34-2 whereas the Xen tree embeds v1.0.0 itself. Could be
> worth investigating.
> 
> Ian.
>
 
>
-----------------------------------------------------------------------------------------------------------------------------
> 
> Same file is in  XEN 4.1.1 Ubuntu Oneiric packaging :
> 
> boris@boris-System-P5Q3:~/CHUCK-STUFF/xen-4.1.1/debian/patches$ ls -l
tools-firmware-etherboot-packaged.diff
> 
> -rw-r--r-- 1 boris boris 1464 2011-07-28 21:17
tools-firmware-etherboot-packaged.diff
> 
> 
> Boris.
> --- On Thu, 7/28/11, Keir Fraser <keir.xen@gmail.com> wrote:
> 
> From: Keir Fraser <keir.xen@gmail.com>
> Subject: Re: [Xen-devel] Re: Attempt to backport changeset-23088,
changeset-23089 to Xen 4.1.1
> To: "Boris Derzhavets" <bderzhavets@yahoo.com>
> Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
> Date: Thursday, July 28, 2011, 3:53 PM
> 
> On 28/07/2011 20:41, "Boris Derzhavets"
<bderzhavets@yahoo.com> wrote:
> 
>> Only 3 CSs backported :-
>> changeset
 23104  - No problems . HVM fix
>> Next step =>  23088 and 23089 .  This step causes build failure.
> 
> Is that 23089:8ec7808f9c23 and 23088:49728fe8dd6a? There is zero chance of
> either of those being the cause of a build failure under tools/firmware.
> 
>  -- Keir
> 
>> Boris.
>>
>> --- On Thu, 7/28/11, Keir Fraser <keir.xen@gmail.com> wrote:
>>>
>>> From: Keir Fraser <keir.xen@gmail.com>
>>> Subject: [Xen-devel] Re: Attempt to backport changeset-23088,
changeset-23089
>>> to Xen 4.1.1
>>> To: "Boris Derzhavets" <bderzhavets@yahoo.com>
>>> Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
>>> "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Konrad
>>> Rzeszutek Wilk" <konrad.wilk@oracle.com>
>>> Date: Thursday, July 28, 2011, 3:04 PM
>>>
>>> On 28/07/2011 18:58, "Boris Derzhavets"
<bderzhavets@yahoo.com
>>>
 </mc/compose?to=bderzhavets@yahoo.com> >
wrote:
>>>
>>>> Build  error :-
>>>
>>> The stated changesets don''t touch tools/firmware.
They''re unlikely to be
>>> causing your build failure.
>>>
>>>   -- Keir
>>>
>>>> Calculated checksum:  0x44  Setting checksum.
>>>> ls -l VGABIOS-lgpl-latest.cirrus.debug.bin
>>>> -rw-rw-r-- 1 buildd buildd 35840 Jul 28 17:27
>>>> VGABIOS-lgpl-latest.cirrus.debug.bin
>>>> make[8]: Leaving directory
>>>>
>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/vgabio
>>> s>
>>> ''
>>>> make[7]: Leaving directory
>>>>
 `/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>>> make[7]: Entering directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>>> /usr/bin/make -C etherboot all
>>>> make[8]: Entering directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/ether
>>>> bo
>>>> ot''
>>>> make[8]: *** No rule to make target
`/usr/lib/ipxe/rtl8139.rom'', needed by
>>>> `eb-roms.h''.  Stop.
>>>> make[8]: Leaving directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware/ether
>>>> bo
>>>> ot''
>>>> make[7]: *** [subdir-all-etherboot] Error 2
>>>> make[7]: Leaving directory
>>>>
 `/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>>> make[6]: *** [subdirs-all] Error 2
>>>> make[6]: Leaving directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>>> make[5]: *** [all] Error 2
>>>> make[5]: Leaving directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools/firmware''
>>>> make[4]: *** [subdir-all-firmware] Error 2
>>>> make[4]: Leaving directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools''
>>>> make[3]: *** [subdirs-all] Error 2
>>>> make[3]: Leaving directory
>>>>
`/build/buildd/xen-4.1.1/debian/build/build-utils_amd64/tools''
>>>> make[2]: *** [debian/stamps/build-utils_amd64] Error 2
>>>> make[2]: Leaving directory
 `/build/buildd/xen-4.1.1''
>>>> make[1]: *** [build_amd64_real] Error 2
>>>> make[1]: Leaving directory `/build/buildd/xen-4.1.1''
>>>> make: *** [debian/stamps/build-base] Error 2
>>>> dpkg-buildpackage: error: debian/rules build gave error exit
status 2
>>>>
>>>> Boris.
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
</mc/compose?to=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

-----Inline Attachment Follows-----

_______________________________________________
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