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

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

[Stefan Bader]

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

Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD"

[Stefano Stabellini]

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");

Re: Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD"

[Ian Campbell]

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

Re: Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD"

[Stefan Bader]

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

Re: Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD"

[Stefano Stabellini]

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?

Re: Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD"

[Stefan Bader]

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

Re: Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD"

[Stefano Stabellini]

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?

Re: Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD"

[Stefan Bader]

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

Re: Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD"

[Stefano Stabellini]

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.

Re: Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD"

[John Haxby]

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

Re: Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD"

[Stefan Bader]

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

[PATCH 1/3] xen-blkfront: Drop name and minor adjustments for emulated scsi devices

[Stefan Bader]

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

Re: [PATCH 1/3] xen-blkfront: Drop name and minor adjustments for emulated scsi devices

[Stefano Stabellini]

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
> 

[PATCH 2/3] xen-blkfront: Fix one off warning about name clash

[Stefan Bader]

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

Re: [PATCH 2/3] xen-blkfront: Fix one off warning about name clash

[Stefano Stabellini]

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
> 

[PATCH 3/3] xen-blkfront: Fix minor offset calculation for emulated IDE disks

[Stefan Bader]

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

Re: [PATCH 3/3] xen-blkfront: Fix minor offset calculation for emulated IDE disks

[Stefano Stabellini]

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
> 

Re: [PATCH 3/3] xen-blkfront: Fix minor offset calculation for emulated IDE disks

[Stefan Bader]

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

Re: [PATCH 3/3] xen-blkfront: Fix minor offset calculation for emulated IDE disks

[Stefano Stabellini]

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.

Re: [PATCH 3/3] xen-blkfront: Fix minor offset calculation for emulated IDE disks

[Stefan Bader]

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.

Re: [PATCH 3/3] xen-blkfront: Fix minor offset calculation for emulated IDE disks

[Konrad Rzeszutek Wilk]

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

Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot) (HVM DomUs crash)

[Boris Derzhavets]

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

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.





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

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

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

Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot) (HVM DomUs crash)

[Konrad Rzeszutek Wilk]

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

Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot) (HVM DomUs crash)

[Boris Derzhavets]

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

> 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

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

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

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

Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot) (HVM DomUs crash)

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]

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.

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

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

Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot) (HVM DomUs crash)

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 1835 bytes --]

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?

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

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

Re: Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot) (HVM DomUs crash)

[Boris Derzhavets]

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

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

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

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

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

Re: Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot) (HVM DomUs crash)

[Ian Campbell]

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.

Re: Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot) (HVM DomUs crash)

[Boris Derzhavets]

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

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

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

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

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

Re: Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot) (HVM DomUs crash)

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 315 bytes --]

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.

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

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

Re: Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot) (HVM DomUs crash)

[Boris Derzhavets]

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

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

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

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

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

Re: Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot) (HVM DomUs crash)

[Boris Derzhavets]

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

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.

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

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

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

Re: Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot) (HVM DomUs crash)

[Stefan Bader]

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

Re: Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot) (HVM DomUs crash)

[Keir Fraser]

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
> 

Re: Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot) (HVM DomUs crash)

[Boris Derzhavets]

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

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
> 



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

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

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

Re: Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot) (HVM DomUs crash)

[Ian Campbell]

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.

Re: Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot) (HVM DomUs crash)

[Boris Derzhavets]

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

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

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

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

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

Attempt to backport changeset-23088, changeset-23089 to Xen 4.1.1

[Boris Derzhavets]

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

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.


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

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

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

Re: Attempt to backport changeset-23088, changeset-23089 to Xen 4.1.1

[Keir Fraser]

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

Re: Re: Attempt to backport changeset-23088, changeset-23089 to Xen 4.1.1

[Boris Derzhavets]

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

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

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

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

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

Re: Re: Attempt to backport changeset-23088, changeset-23089 to Xen 4.1.1

[Keir Fraser]

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
> 

Re: Re: Attempt to backport changeset-23088, changeset-23089 to Xen 4.1.1

[Boris Derzhavets]

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

>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

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

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

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

Re: Re: Attempt to backport changeset-23088, changeset-23089 to Xen 4.1.1

[Keir Fraser]

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
> 

Re: Re: Attempt to backport changeset-23088, changeset-23089 to Xen 4.1.1- Notice of Ian Campbell

[Boris Derzhavets]

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

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

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

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

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

Re: Re: Attempt to backport changeset-23088, changeset-23089 to Xen 4.1.1- Notice of Ian Campbell

[Stefan Bader]

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

Re: Re: Attempt to backport changeset-23088, changeset-23089 to Xen 4.1.1- Notice of Ian Campbell

[Boris Derzhavets]

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

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


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

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

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

Re: Re: Attempt to backport changeset-23088, changeset-23089 to Xen 4.1.1- Notice of Ian Campbell

[Boris Derzhavets]

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

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

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

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

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

problem with xentrace_format in Xen 4.0.1

[Zhiyuan Shao]

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

Re: Re: Problem with Xen 4.1 on Ubuntu 11.10 ( Oneiric Ocelot) (HVM DomUs crash)

[Boris Derzhavets]

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

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

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

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

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

Re: Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD"

[Ian Campbell]

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

Re: Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD"

[Stefan Bader]

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

Re: Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD"

[Ian Jackson]

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.