Re: FreeBSD PVHVM call for testing

[Julian Elischer]

On 10/11/13 9:56 PM, Roger Pau Monné wrote:

On 11/10/13 11:42, Eggert, Lars wrote:

Hi,

On May 13, 2013, at 20:32, Roger Pau Monné  wrote:

Right now the code is in a state where it can be tested by users, so we
would like to encourage FreeBSD and Xen users to test it and provide
feedback.

any idea if/when this code will be merged into -CURRENT?

It's already in HEAD, and will hopefully be part of the 10 release.

my testing On Amazon  shows a noticeable slowdown from 9-stable.



Roger.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"





___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

On 11/10/13 11:42, Eggert, Lars wrote:
> Hi,
> 
> On May 13, 2013, at 20:32, Roger Pau Monné  wrote:
>> Right now the code is in a state where it can be tested by users, so we
>> would like to encourage FreeBSD and Xen users to test it and provide
>> feedback.
> 
> any idea if/when this code will be merged into -CURRENT?

It's already in HEAD, and will hopefully be part of the 10 release.

Roger.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Eggert, Lars]

Hi,

On May 13, 2013, at 20:32, Roger Pau Monné  wrote:
> Right now the code is in a state where it can be tested by users, so we
> would like to encourage FreeBSD and Xen users to test it and provide
> feedback.

any idea if/when this code will be merged into -CURRENT?

Thanks,
Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: FreeBSD PVHVM call for testing

[Jeroen van der Ham]

Hi,

On 22 Jul 2013, at 10:40, Jeroen van der Ham  wrote:
>> Could you also try a HEAD XENHVM kernel (without my patches), to see if
>> the issue is related to my changes or to some bug already present in HEAD?

It seems I was worrying too soon.

I have been putting the system through the wringer some more, and I now believe 
that it has been caused by adding a new swap file. Just before I rebooted my 
system I created a larger swap file to be used by /etc/rc.d/add_swap.
Right after I rebooted I started compiling and doing other things. And I am 
getting the feeling that the system was still initialising that swap file and 
was unable to provide swap space at that time.

I've rebooted my system again with the PVHVM system, abused it even more than I 
did before and I'm not seeing the same messages again, nor getting any 
exaggerated sluggishness.

So my apologies for the false alarm.

Jeroen.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

On 22/07/13 10:40, Jeroen van der Ham wrote:
> Hi,
> 
> On 22 Jul 2013, at 10:29, Roger Pau Monné  wrote:
>> Is your guest running a 32bit or a 64bit kernel?
> 
> $ uname -a
> FreeBSD positron.dckd.nl 10.0-CURRENT FreeBSD 10.0-CURRENT #0 
> r+a09eac7-dirty: Wed Jul 17 17:51:10 CEST 2013 
> root@image01:/usr/obj/usr/home/jeroen/freebsd/sys/XENHVM  amd64
> 
>>
>> Could you also provide the config file used to launch your guest and the
>> Xen and Dom0 kernel versions?
> 
> Guest config:
> 
> kernel = '/usr/lib/xen-4.0/boot/hvmloader'
> device_model = '/usr/lib/xen-4.0/bin/qemu-dm'
> builder = 'hvm'
> shadow_memory = 8

Are you setting the shadow memory size manually because your hardware
lacks HAP support?

> memory = 512
> name = "positron"
> vcpus = 2
> cpus = "2-7"
> maxvcpus = 4
> xen_shell = 'root, jeroen'

This doesn't seem like a standard xl config option.

> 
> vif = [
> 'type=vifname=positron.wan,bridge=br-wan,mac=00:16:3E:2F:AD:99,ip=94.142.246.99'
> ,
> 'type=vifname=positron.lan,bridge=br-lan,mac=00:16:3E:0D:96:5C,ip=10.20.0.99'
> ]
> 
> disk = ['phy:/xen/domains/positron/positron-disk1,hda,w']
> 
> xen_platform_pci=1
> boot = 'c'
> sdl=0
> stdvga=0
> serial='pty'
> 
> 
> Xen info:
> 
> host   : soleus01.soleus.nu
> release: 2.6.32-5-xen-amd64
> version: #1 SMP Mon Oct 3 07:53:54 UTC 2011
> machine: x86_64
> nr_cpus: 8
> nr_nodes   : 2
> cores_per_socket   : 4
> threads_per_core   : 1
> cpu_mhz: 2200
> hw_caps: 
> 178bf3ff:efd3fbff::1310:00802001::37ff:
> virt_caps  : hvm
> total_memory   : 65534
> free_memory: 6865
> node_to_cpu: node0:0-3
>  node1:4-7
> node_to_memory : node0:3128
>  node1:3737
> node_to_dma32_mem  : node0:3128
>  node1:0
> max_node_id: 1
> xen_major  : 4
> xen_minor  : 0
> 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=0x8000
> xen_changeset  : unavailable
> xen_commandline: placeholder dom0_mem=1852M
> cc_compiler: gcc version 4.4.5 (Debian 4.4.5-10)
> cc_compile_by  : waldi
> cc_compile_domain  : debian.org
> cc_compile_date: Wed Jan 12 14:04:06 UTC 2011
> xend_config_format : 4

I've set up a XENHVM system with 256MB of RAM and swap and this is what
I see when doing a make buildkernel:

[root@ ~]# swapinfo
Device  1K-blocks UsedAvail Capacity
/dev/ada0p3   1048540   351116   69742433%

I don't see any messages on the console or anything else, the system
seems to be sluggish while doing the build, but that's quite normal when
using only 256MB of RAM.

This test was done using the pvhvm_20 branch, but it should not contain
any significant code changes in comparison with pvhvm_v19 (it's just a
rebase on top of HEAD and a reorder of patches). Could this be because
you are using a 9 userland with a 10 kernel?

Roger.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Jeroen van der Ham]

Hi,

On 22 Jul 2013, at 10:29, Roger Pau Monné  wrote:
> Is your guest running a 32bit or a 64bit kernel?

$ uname -a
FreeBSD positron.dckd.nl 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r+a09eac7-dirty: 
Wed Jul 17 17:51:10 CEST 2013 
root@image01:/usr/obj/usr/home/jeroen/freebsd/sys/XENHVM  amd64

> 
> Could you also provide the config file used to launch your guest and the
> Xen and Dom0 kernel versions?

Guest config:

kernel = '/usr/lib/xen-4.0/boot/hvmloader'
device_model = '/usr/lib/xen-4.0/bin/qemu-dm'
builder = 'hvm'
shadow_memory = 8
memory = 512
name = "positron"
vcpus = 2
cpus = "2-7"
maxvcpus = 4
xen_shell = 'root, jeroen'

vif = [
'type=vifname=positron.wan,bridge=br-wan,mac=00:16:3E:2F:AD:99,ip=94.142.246.99'
,
'type=vifname=positron.lan,bridge=br-lan,mac=00:16:3E:0D:96:5C,ip=10.20.0.99'
]

disk = ['phy:/xen/domains/positron/positron-disk1,hda,w']

xen_platform_pci=1
boot = 'c'
sdl=0
stdvga=0
serial='pty'


Xen info:

host   : soleus01.soleus.nu
release: 2.6.32-5-xen-amd64
version: #1 SMP Mon Oct 3 07:53:54 UTC 2011
machine: x86_64
nr_cpus: 8
nr_nodes   : 2
cores_per_socket   : 4
threads_per_core   : 1
cpu_mhz: 2200
hw_caps: 
178bf3ff:efd3fbff::1310:00802001::37ff:
virt_caps  : hvm
total_memory   : 65534
free_memory: 6865
node_to_cpu: node0:0-3
 node1:4-7
node_to_memory : node0:3128
 node1:3737
node_to_dma32_mem  : node0:3128
 node1:0
max_node_id: 1
xen_major  : 4
xen_minor  : 0
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=0x8000
xen_changeset  : unavailable
xen_commandline: placeholder dom0_mem=1852M
cc_compiler: gcc version 4.4.5 (Debian 4.4.5-10)
cc_compile_by  : waldi
cc_compile_domain  : debian.org
cc_compile_date: Wed Jan 12 14:04:06 UTC 2011
xend_config_format : 4

> Could you also try a HEAD XENHVM kernel (without my patches), to see if
> the issue is related to my changes or to some bug already present in HEAD?

Will do.


Jeroen.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

On 22/07/13 09:18, Jeroen van der Ham wrote:
> Hi,
> 
> After some more testing I thought it would be good to put this into 
> production for my personal server. I've used pvhvm_v19 and built it without 
> debugging options and installed it on a FreeBSD 9.1 system.
> 
> I've run into some hiccups with 9.1 user land and a 10-CURRENT kernel, but 
> that's all solvable[0].
> 
> My VPS has some very limited memory (256M), but I've compensated with swap 
> space (1G)

Is your guest running a 32bit or a 64bit kernel?

Could you also provide the config file used to launch your guest and the
Xen and Dom0 kernel versions?

> 
> Now anytime I'm putting the system under stress, by building ports or by 
> running a git clone on the kernel repository here, I'm seeing a lot of 
> messages about swap_pager:
> 
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 132545, size: 4096
> 
> The system also becomes very sluggish and sometimes unresponsive.
> The weird thing was that one of these messages happened right after a reboot 
> when I rebuilt an outdated port and on the main console was checking the swap 
> memory:
> 
>> jeroen:~/ $ swapinfo  
>> [8:13:29]
>> Device  1K-blocks UsedAvail Capacity
>> /dev/ada0p2524288 2484   521804 0%
>> /dev/md0  1048576 2364  1046212 0%
>> Total 1572864 4848  1568016 0%
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 131424, size: 4096
> 
> 
> Is anyone else seeing something similar?

Could you also try a HEAD XENHVM kernel (without my patches), to see if
the issue is related to my changes or to some bug already present in HEAD?

> I certainly did not experience something like this on 9.0 with a XENHVM 
> kernel.
> 
> If necessary I can rebuild a kernel with debugging support and do some more 
> recording of what is actually going on.
> 
> Jeroen.
> 
> 
> [0]: I have edited bsd.port.mk to always apply the FBSD10_FIX, and for 
> version checking I am  running "pkg version" with UNAME_r=9.1-RELEASE.
> 

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Jeroen van der Ham]

Hi,

After some more testing I thought it would be good to put this into production 
for my personal server. I've used pvhvm_v19 and built it without debugging 
options and installed it on a FreeBSD 9.1 system.

I've run into some hiccups with 9.1 user land and a 10-CURRENT kernel, but 
that's all solvable[0].

My VPS has some very limited memory (256M), but I've compensated with swap 
space (1G)

Now anytime I'm putting the system under stress, by building ports or by 
running a git clone on the kernel repository here, I'm seeing a lot of messages 
about swap_pager:

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 132545, size: 4096

The system also becomes very sluggish and sometimes unresponsive.
The weird thing was that one of these messages happened right after a reboot 
when I rebuilt an outdated port and on the main console was checking the swap 
memory:

> jeroen:~/ $ swapinfo  
> [8:13:29]
> Device  1K-blocks UsedAvail Capacity
> /dev/ada0p2524288 2484   521804 0%
> /dev/md0  1048576 2364  1046212 0%
> Total 1572864 4848  1568016 0%
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 131424, size: 4096


Is anyone else seeing something similar?
I certainly did not experience something like this on 9.0 with a XENHVM kernel.

If necessary I can rebuild a kernel with debugging support and do some more 
recording of what is actually going on.

Jeroen.


[0]: I have edited bsd.port.mk to always apply the FBSD10_FIX, and for version 
checking I am  running "pkg version" with UNAME_r=9.1-RELEASE.
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Jeroen van der Ham]

Hi,

On 20 Jun 2013, at 11:33, Roger Pau Monné  wrote:
> 
> This is probably due to the fact that we are not properly accounting for
> blocked/runnable/offline time. Did you see the same when running the
> XENHVM kernel without my patches?
> 

I have a different system on the same platform running FreeBSD9 with XENHVM. 
This server is running (web)mail, smokeping and irssi.

That gives:

 11:35AM  up 20:07, 1 user, load averages: 0.06, 0.06, 0.07

Jeroen.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

On 20/06/13 11:20, Jeroen van der Ham wrote:
> Hi,
> 
> I have this running for a day or so now, but I'm noticing that the load 
> averages seem a bit off:
> 
> $ uptime
> 11:17AM  up 17:14, 1 user, load averages: 0.31, 0.27, 0.21
> 
> This is for a clean install, with just enough installed to compile this 
> kernel. In top I'm seeing that the machine is idling >98% of the time. But 
> this does not correlate to the load displayed above.

This is probably due to the fact that we are not properly accounting for
blocked/runnable/offline time. Did you see the same when running the
XENHVM kernel without my patches?

Roger.
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Jeroen van der Ham]

Hi,

I have this running for a day or so now, but I'm noticing that the load 
averages seem a bit off:

$ uptime
11:17AM  up 17:14, 1 user, load averages: 0.31, 0.27, 0.21

This is for a clean install, with just enough installed to compile this kernel. 
In top I'm seeing that the machine is idling >98% of the time. But this does 
not correlate to the load displayed above.

Jeroen.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Jeroen van der Ham]

Hi,

On 19 Jun 2013, at 18:52, Justin T. Gibbs  wrote:
>> I guess the kernel-toolchain takes a long time to build…and from what I can 
>> see it does a clean before rebuilding also.
>> 
>> I'm doing the kernel-toolchain step only now and will report how long it 
>> took.

This seems to be it, that took roughly 2 hours to build. The actual kernel is 
probably pretty fast in building.

> Oh.  Without any parallelism (-j X), the build will take a really long time.  
> Even with only one core, you'll get a large speedup by performing a parallel 
> build since many steps of the build are I/O bound.

Neither of the systems actually had parallelism defined, either as flag or in 
/etc/make.conf

Jeroen.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Justin T. Gibbs]

On Jun 19, 2013, at 10:50 AM, Jeroen van der Ham  wrote:

> Hi,
> 
> On 19 Jun 2013, at 18:15, Justin T. Gibbs  wrote:
>> 
>> I've never seen a kernel build take 2 hours, much less 2 hours *longer*.  
>> Are you talking about buildworld?  It would be interesting to know your 
>> results building stable/9 sources in your 10 environment to see if this is 
>> just due to "build bloat" or a true performance regression.
>> 
> 
> I copy/pasted the command from the wiki:
> 
>> # make kernel-toolchain && make buildkernel KERNCONF=XENHVM && make 
>> installkernel KERNCONF=XENHVM
> 
> On the stable/9 I only did 
> 
>> make buildkernel KERNCONF=XENHVM && make installkernel KERNCONF=XENHVM
> 
> 
> I guess the kernel-toolchain takes a long time to build…and from what I can 
> see it does a clean before rebuilding also.
> 
> I'm doing the kernel-toolchain step only now and will report how long it took.
> 
> Jeroen.

Oh.  Without any parallelism (-j X), the build will take a really long time.  
Even with only one core, you'll get a large speedup by performing a parallel 
build since many steps of the build are I/O bound.

--
Justin
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Jeroen van der Ham]

Hi,

On 19 Jun 2013, at 18:15, Justin T. Gibbs  wrote:
> 
> I've never seen a kernel build take 2 hours, much less 2 hours *longer*.  Are 
> you talking about buildworld?  It would be interesting to know your results 
> building stable/9 sources in your 10 environment to see if this is just due 
> to "build bloat" or a true performance regression.
> 

I copy/pasted the command from the wiki:

> # make kernel-toolchain && make buildkernel KERNCONF=XENHVM && make 
> installkernel KERNCONF=XENHVM

On the stable/9 I only did 

> make buildkernel KERNCONF=XENHVM && make installkernel KERNCONF=XENHVM


I guess the kernel-toolchain takes a long time to build…and from what I can see 
it does a clean before rebuilding also.

I'm doing the kernel-toolchain step only now and will report how long it took.

Jeroen.



___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Justin T. Gibbs]

On Jun 19, 2013, at 10:07 AM, Jeroen van der Ham  wrote:

> Hi,
> 
> On 19 Jun 2013, at 14:44, Roger Pau Monné  wrote:
> 
>> On 19/06/13 14:33, Jeroen van der Ham wrote:
>>> 
>>> On 19 Jun 2013, at 14:20, Roger Pau Monné  wrote:
 That's because Justin recently pushed a commit that changed the ad
 translation to ada, you should change your /etc/fstab to ada0p2. It's
 commit 526f3ad11acb296481215d7c2915b3f30f1844f6.
>>> 
>>> 
>>> Ah, you may want to update the wiki page also to warn for that. :)
>> 
>> D'oh, I've completely forgot about the wiki page, it's updated now,
>> thanks for the pointer.
> 
> Okay, everything works again now.

Should we encourage folks to just configure their VMs to use xbd?  I hope some 
day that the system will just report "da" devices, so the ada name may change 
again.  We could also suggest specifying SCSI disks in the VM config since I 
don't think "da" will ever change.

> Additionally, I've applied the patches from FreeBSD-SA-13:06.mmap, rebuilt 
> the kernel and rebooted, and the system now works fine.
> 
> I did note however that rebuilding the kernel takes an awful lot more time 
> than on a FreeBSD9 system. As in it took about 2 hours longer.
> 
> Jeroen.

I've never seen a kernel build take 2 hours, much less 2 hours *longer*.  Are 
you talking about buildworld?  It would be interesting to know your results 
building stable/9 sources in your 10 environment to see if this is just due to 
"build bloat" or a true performance regression.

--
Justin
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Jeroen van der Ham]

Hi,

On 19 Jun 2013, at 14:44, Roger Pau Monné  wrote:

> On 19/06/13 14:33, Jeroen van der Ham wrote:
>> 
>> On 19 Jun 2013, at 14:20, Roger Pau Monné  wrote:
>>> That's because Justin recently pushed a commit that changed the ad
>>> translation to ada, you should change your /etc/fstab to ada0p2. It's
>>> commit 526f3ad11acb296481215d7c2915b3f30f1844f6.
>> 
>> 
>> Ah, you may want to update the wiki page also to warn for that. :)
> 
> D'oh, I've completely forgot about the wiki page, it's updated now,
> thanks for the pointer.

Okay, everything works again now.

Additionally, I've applied the patches from FreeBSD-SA-13:06.mmap, rebuilt the 
kernel and rebooted, and the system now works fine.

I did note however that rebuilding the kernel takes an awful lot more time than 
on a FreeBSD9 system. As in it took about 2 hours longer.

Jeroen.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

On 19/06/13 14:33, Jeroen van der Ham wrote:
> 
> On 19 Jun 2013, at 14:20, Roger Pau Monné  wrote:
>> That's because Justin recently pushed a commit that changed the ad
>> translation to ada, you should change your /etc/fstab to ada0p2. It's
>> commit 526f3ad11acb296481215d7c2915b3f30f1844f6.
> 
> 
> Ah, you may want to update the wiki page also to warn for that. :)

D'oh, I've completely forgot about the wiki page, it's updated now,
thanks for the pointer.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Jeroen van der Ham]

On 19 Jun 2013, at 14:20, Roger Pau Monné  wrote:
> That's because Justin recently pushed a commit that changed the ad
> translation to ada, you should change your /etc/fstab to ada0p2. It's
> commit 526f3ad11acb296481215d7c2915b3f30f1844f6.


Ah, you may want to update the wiki page also to warn for that. :)

Jeroen.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

On 19/06/13 14:16, Jeroen van der Ham wrote:
> 
> On 19 Jun 2013, at 13:34, Roger Pau Monné  wrote:
>>
>> Could you provide the boot log of the DomU, backtrace, Xen version and
>> Dom0 kernel version?
> 
> I did not have a console attached when it rebooted, so I did not have a log 
> of the initial boot. Now that I did, I see that it fails to mount its root 
> volume.
> 
> It had been running previously on pvhvm_v10 for about two weeks without 
> problems. I updated my local git, and recompiled the kernel and rebooted. 
> Then this happened.
> 
> 
> In order:
> 
> Booting...
> GDB: no debug ports present
> KDB: debugger backends: ddb
> KDB: current backend: ddb
> Copyright (c) 1992-2013 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>   The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 10.0-CURRENT #2 r+6ff8d00-dirty: Tue Jun 18 12:55:16 CEST 2013
> root@image01:/usr/obj/root/freebsd/sys/XENHVM amd64
> FreeBSD clang version 3.3 (trunk 178860) 20130405
> WARNING: WITNESS option enabled, expect reduced performance.
> XEN: Hypervisor version 4.0 detected.
> CPU: Quad-Core AMD Opteron(tm) Processor 2374 HE (2200.07-MHz K8-class CPU)
>   Origin = "AuthenticAMD"  Id = 0x100f42  Family = 0x10  Model = 0x4  
> Stepping = 2
>   
> Features=0x1781fbff
>   Features2=0x80802001
>   AMD Features=0xe2500800
>   AMD Features2=0x1f3
> real memory  = 536870912 (512 MB)
> avail memory = 472260608 (450 MB)
> Event timer "LAPIC" quality 400
> ACPI APIC Table: 
> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
> FreeBSD/SMP: 1 package(s) x 2 core(s)
>  cpu0 (BSP): APIC ID:  0
>  cpu1 (AP): APIC ID:  2
> random device not loaded; using insecure entropy
> ioapic0: Changing APIC ID to 1
> MADT: Forcing active-low polarity and level trigger for SCI
> ioapic0  irqs 0-47 on motherboard
> kbd1 at kbdmux0
> xen_et0:  on motherboard
> Event timer "XENTIMER" frequency 10 Hz quality 950
> Timecounter "XENTIMER" frequency 10 Hz quality 950
> acpi0:  on motherboard
> acpi0: Power Button (fixed)
> acpi0: Sleep Button (fixed)
> acpi0: reservation of 0, a (3) failed
> cpu0:  on acpi0
> cpu1:  on acpi0
> attimer0:  port 0x40-0x43 irq 0 on acpi0
> Timecounter "i8254" frequency 1193182 Hz quality 0
> Event timer "i8254" frequency 1193182 Hz quality 100
> atrtc0:  port 0x70-0x71 irq 8 on acpi0
> Event timer "RTC" frequency 32768 Hz quality 0
> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x1f48-0x1f4b on acpi0
> pcib0:  port 0xcf8-0xcff on acpi0
> pci0:  on pcib0
> isab0:  at device 1.0 on pci0
> isa0:  on isab0
> atapci0:  port 
> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc300-0xc30f at device 1.1 on pci0
> ata0:  at channel 0 on atapci0
> ata1:  at channel 1 on atapci0
> pci0:  at device 1.3 (no driver attached)
> vgapci0:  mem 
> 0xf000-0xf1ff,0xf300-0xf3000fff at device 2.0 on pci0
> xenpci0:  port 0xc000-0xc0ff mem 0xf200-0xf2ff 
> irq 28 at device 3.0 on pci0
> xenstore0:  on xenpci0
> atkbdc0:  port 0x60,0x64 irq 1 on acpi0
> atkbd0:  irq 1 on atkbdc0
> kbd0 at atkbd0
> atkbd0: [GIANT-LOCKED]
> psm0:  irq 12 on atkbdc0
> psm0: [GIANT-LOCKED]
> psm0: model IntelliMouse Explorer, device ID 4
> fdc0:  port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
> fdc0: does not respond
> device_attach: fdc0 attach returned 6
> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
> uart0: console (9600,n,8,1)
> ppc0:  port 0x378-0x37f irq 7 on acpi0
> ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
> ppbus0:  on ppc0
> lpt0:  on ppbus0
> lpt0: Interrupt-driven port
> ppi0:  on ppbus0
> orm0:  at iomem 0xc9000-0xc97ff on isa0
> sc0:  at flags 0x100 on isa0
> sc0: VGA <16 virtual consoles, flags=0x300>
> vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
> fdc0: No FDOUT register!
> Timecounters tick every 10.000 msec
> xenbusb_front0:  on xenstore0
> cd0 at ata1 bus 0 scbus1 target 0 lun 0
> cd0:  Removable CD-ROM SCSI-0 device
> cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes)
> cd0: cd present [360385 x 2048 byte records]
> xn0:  at device/vif/0 on xenbusb_front0
> xn0: Ethernet address: 00:16:3e:2f:b7:22
> xn1:  at device/vif/1 on xenbusb_front0
> xn1: Ethernet address: 00:16:3e:3e:64:c5
> xenbusb_back0:  on xenstore0
> xctrl0:  on xenstore0
> xn0: backend features: feature-sg feature-gso-tcp4
> xn1: backend features: feature-sg feature-gso-tcp4
> xbd0: 20480MB  at device/vbd/768 on xenbusb_front0
> xbd0: attaching as ada0
> xbd0: disk supports cache flush using: barriers
> xbd1: 703MB  at device/vbd/5632 on xenbusb_front0
> xbd1: attaching as ada2
> xbd1: disk supports cache flush using: barriers
> SMP: AP CPU #1 Launched!
> WARNING: WITNESS option enabled, expect reduced performance.
> Trying to mount root from ufs:/dev/ad0p2 [rw]...
> mountroot: waiting for device 

Re: FreeBSD PVHVM call for testing

[Jeroen van der Ham]

On 19 Jun 2013, at 13:34, Roger Pau Monné  wrote:
> 
> Could you provide the boot log of the DomU, backtrace, Xen version and
> Dom0 kernel version?

I did not have a console attached when it rebooted, so I did not have a log of 
the initial boot. Now that I did, I see that it fails to mount its root volume.

It had been running previously on pvhvm_v10 for about two weeks without 
problems. I updated my local git, and recompiled the kernel and rebooted. Then 
this happened.


In order:

Booting...
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-CURRENT #2 r+6ff8d00-dirty: Tue Jun 18 12:55:16 CEST 2013
root@image01:/usr/obj/root/freebsd/sys/XENHVM amd64
FreeBSD clang version 3.3 (trunk 178860) 20130405
WARNING: WITNESS option enabled, expect reduced performance.
XEN: Hypervisor version 4.0 detected.
CPU: Quad-Core AMD Opteron(tm) Processor 2374 HE (2200.07-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0x100f42  Family = 0x10  Model = 0x4  Stepping 
= 2
  
Features=0x1781fbff
  Features2=0x80802001
  AMD Features=0xe2500800
  AMD Features2=0x1f3
real memory  = 536870912 (512 MB)
avail memory = 472260608 (450 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  2
random device not loaded; using insecure entropy
ioapic0: Changing APIC ID to 1
MADT: Forcing active-low polarity and level trigger for SCI
ioapic0  irqs 0-47 on motherboard
kbd1 at kbdmux0
xen_et0:  on motherboard
Event timer "XENTIMER" frequency 10 Hz quality 950
Timecounter "XENTIMER" frequency 10 Hz quality 950
acpi0:  on motherboard
acpi0: Power Button (fixed)
acpi0: Sleep Button (fixed)
acpi0: reservation of 0, a (3) failed
cpu0:  on acpi0
cpu1:  on acpi0
attimer0:  port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
atrtc0:  port 0x70-0x71 irq 8 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x1f48-0x1f4b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
isab0:  at device 1.0 on pci0
isa0:  on isab0
atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc300-0xc30f at device 1.1 on pci0
ata0:  at channel 0 on atapci0
ata1:  at channel 1 on atapci0
pci0:  at device 1.3 (no driver attached)
vgapci0:  mem 
0xf000-0xf1ff,0xf300-0xf3000fff at device 2.0 on pci0
xenpci0:  port 0xc000-0xc0ff mem 0xf200-0xf2ff irq 
28 at device 3.0 on pci0
xenstore0:  on xenpci0
atkbdc0:  port 0x60,0x64 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
psm0:  irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: model IntelliMouse Explorer, device ID 4
fdc0:  port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: does not respond
device_attach: fdc0 attach returned 6
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: console (9600,n,8,1)
ppc0:  port 0x378-0x37f irq 7 on acpi0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
ppbus0:  on ppc0
lpt0:  on ppbus0
lpt0: Interrupt-driven port
ppi0:  on ppbus0
orm0:  at iomem 0xc9000-0xc97ff on isa0
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
fdc0: No FDOUT register!
Timecounters tick every 10.000 msec
xenbusb_front0:  on xenstore0
cd0 at ata1 bus 0 scbus1 target 0 lun 0
cd0:  Removable CD-ROM SCSI-0 device
cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes)
cd0: cd present [360385 x 2048 byte records]
xn0:  at device/vif/0 on xenbusb_front0
xn0: Ethernet address: 00:16:3e:2f:b7:22
xn1:  at device/vif/1 on xenbusb_front0
xn1: Ethernet address: 00:16:3e:3e:64:c5
xenbusb_back0:  on xenstore0
xctrl0:  on xenstore0
xn0: backend features: feature-sg feature-gso-tcp4
xn1: backend features: feature-sg feature-gso-tcp4
xbd0: 20480MB  at device/vbd/768 on xenbusb_front0
xbd0: attaching as ada0
xbd0: disk supports cache flush using: barriers
xbd1: 703MB  at device/vbd/5632 on xenbusb_front0
xbd1: attaching as ada2
xbd1: disk supports cache flush using: barriers
SMP: AP CPU #1 Launched!
WARNING: WITNESS option enabled, expect reduced performance.
Trying to mount root from ufs:/dev/ad0p2 [rw]...
mountroot: waiting for device /dev/ad0p2 ...
Mounting from ufs:/dev/ad0p2 failed with error 19.
Loader variables:
  vfs.root.mountfrom=ufs:/dev/ad0p2
  vfs.root.mountfrom.options=rw

Manual root filesystem specification:
  : [options]
  Mount  using filesystem 
  and with the specified (optional) option list.

eg

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

On 19/06/13 13:13, Jeroen van der Ham wrote:
> Hi,
> 
> I've just built a new kernel based on pvhvm_v17, but it panicked on boot.
> 
> I still have a xen console attached, so I can provide additional information 
> if someone gives me the right commands.
> 
> Jeroen.
> 

Could you provide the boot log of the DomU, backtrace, Xen version and
Dom0 kernel version?
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Jeroen van der Ham]

Hi,

I've just built a new kernel based on pvhvm_v17, but it panicked on boot.

I still have a xen console attached, so I can provide additional information if 
someone gives me the right commands.

Jeroen.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

On 10/06/13 16:48, Roger Pau Monné wrote:
> Hello,
> 
> I've pushed a new branch, pvhvm_v14 that contains support for live
> migration. While there I've also rebased the changes on top of current
> HEAD, so now it contains the recent fixes to blkfront and netfront.
> 
> http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvhvm_v14

Hello,

There where some issues with the previous branch (pvhvm_v14), I've
pushed a new one (pvhvm_v16) that fixes the following bugs:

 * Make sure there are no IPIs in flight while the VM is migrated,
having in-flight IPIs is a problem because on resume the event channels
are re-initialized, so all pending events are lost, including IPIs.

 * Reset the clock after migration, this prevent clock drifts when the
VM is migrated.

 * blkfront was not correctly freeing the old event channel port.

The following two commits are needed for Xen:

f8e8fd56bd7d5675e8331b4ec74bae76c9dbf24e x86/HVM: fix initialization of
wallclock time for PVHVM on migration

32c864a35ece2c24a336d183869a546798a4b241 x86/vtsc: update vcpu_time in
hvm_set_guest_time

With this branch I've been able to successfully local migrate a busy VM
400 times consecutively.

As usual, the branch can be found here:

http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvhvm_v16

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

On 10/06/13 17:09, Outback Dingo wrote:
> 
> 
> 
> On Mon, Jun 10, 2013 at 10:48 AM, Roger Pau Monné  > wrote:
> 
> Hello,
> 
> I've pushed a new branch, pvhvm_v14 that contains support for live
> migration. While there I've also rebased the changes on top of current
> HEAD, so now it contains the recent fixes to blkfront and netfront.
> 
> 
> http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvhvm_v14
> 
> 
> looking at your master branch your 2 weeks behind current... so where
> did you rebase your changes to head, or are you referring to your HEAD,
> and not FreeBSD 

No, my HEAD commit from FreeBSD master repository is from 3 days ago:

http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=commit;h=5311e12c931df9b67b64913670eab76a994317b9

This is the commit where I rebased my pvhvm_v14 branch.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Outback Dingo]

On Mon, Jun 10, 2013 at 10:48 AM, Roger Pau Monné wrote:

> Hello,
>
> I've pushed a new branch, pvhvm_v14 that contains support for live
> migration. While there I've also rebased the changes on top of current
> HEAD, so now it contains the recent fixes to blkfront and netfront.
>
>
> http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvhvm_v14


looking at your master branch your 2 weeks behind current... so where did
you rebase your changes to head, or are you referring to your HEAD, and not
FreeBSD
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

Hello,

I've pushed a new branch, pvhvm_v14 that contains support for live
migration. While there I've also rebased the changes on top of current
HEAD, so now it contains the recent fixes to blkfront and netfront.

http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvhvm_v14

Some notes on this branch, I've mainly tested it with Xen 4.3 (unstable)
because previous Xen versions have problems with the PV clock used in
PVHVM when migrating. In order to be able to migrate a PVHVM guest you
will need to add tsc_mode="native_paravirt" to your config file or apply
the following patch to Xen:

http://marc.info/?l=xen-devel&m=137036010517331

I would say that migration across the 4.x series will work without
problems (because they all have support for vector callback injection),
but migrating from 4.x to 3.x will certainly not work. On the other
hand, migrating a guest started on 3.4 to 4.0 should work, although I
have not tested it.

Also, if the migration process fails for some reason, resuming the
original guest on the sender side will leave the VM without working nics
and disks, this is a problem with netfront and blkfront not being able
to resume after suspension if the guest was not actually migrated.

Roger.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Jeroen van der Ham]

Hi,

On 30 May 2013, at 16:56, Outback Dingo  wrote:
> first is this a public vm ? and if so who is??
> May 29 23:42:30 image01 sshd[31227]: error: Received disconnect from
> 150.165.15.175: 11: Bye Bye [preauth]
> 
> because it is after this potential ssh login attempt, so is this you, has
> there been a breach ? only thing i noticed, but it might be nothing.

This VM is on a public IP indeed, and SSH connectivity is enabled. As with any 
publicly accessible host this then becomes the target of ssh scans.

I included the message just to show that between it and the reboot nothing had 
been logged.

AFAICT there has not been a breach, and I have not seen any indications at all 
that there may be one.

Jeroen.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Outback Dingo]

On Thu, May 30, 2013 at 5:15 AM, Jeroen van der Ham  wrote:

> Hi,
>
> On 30 May 2013, at 11:04, Roger Pau Monné  wrote:
> > So it looks like the system rebooted (but it was not a crash or a
> > sporadic reboot? the kernel seems to be aware of the reboot request). It
> > would be interesting if you could provide the output of the serial
> > console when this happens, that might be helpful. Did you enable
> > xenconsoled logging?
>
> Unfortunately I did not.
>
> > Also, could you provide more info about your system, Xen version, what
> > workload was the DomU running, Dom0 kernel version?
>
> There was no one logged in at the time of the reboot according to the last
> log.
> I did do some sysbench tests during the day, but that was way before it
> rebooted. The only thing that could be running during that time was daily
> periodic.
>
> $ sudo xm info
> host   : soleus01.soleus.nu
> release: 2.6.32-5-xen-amd64
> version: #1 SMP Mon Oct 3 07:53:54 UTC 2011
> machine: x86_64
> nr_cpus: 8
> nr_nodes   : 2
> cores_per_socket   : 4
> threads_per_core   : 1
> cpu_mhz: 2200
> hw_caps:
> 178bf3ff:efd3fbff::1310:00802001::37ff:
> virt_caps  : hvm
> total_memory   : 65534
> free_memory: 6866
> node_to_cpu: node0:0-3
>  node1:4-7
> node_to_memory : node0:3128
>  node1:3737
> node_to_dma32_mem  : node0:3128
>  node1:0
> max_node_id: 1
> xen_major  : 4
> xen_minor  : 0
> 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=0x8000
> xen_changeset  : unavailable
> xen_commandline: placeholder dom0_mem=1852M
> cc_compiler: gcc version 4.4.5 (Debian 4.4.5-10)
> cc_compile_by  : waldi
> cc_compile_domain  : debian.org
> cc_compile_date: Wed Jan 12 14:04:06 UTC 2011
> xend_config_format : 4
>
> $ uname -a
> Linux soleus01.soleus.nu 2.6.32-5-xen-amd64 #1 SMP Mon Oct 3 07:53:54 UTC
> 2011 x86_64 GNU/Linux
>
> Jeroen.
>
>
first is this a public vm ? and if so who is??
May 29 23:42:30 image01 sshd[31227]: error: Received disconnect from
150.165.15.175: 11: Bye Bye [preauth]

because it is after this potential ssh login attempt, so is this you, has
there been a breach ? only thing i noticed, but it might be nothing.




> ___
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-xen
> To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
>
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Jeroen van der Ham]

Hi,

On 30 May 2013, at 11:04, Roger Pau Monné  wrote:
> So it looks like the system rebooted (but it was not a crash or a
> sporadic reboot? the kernel seems to be aware of the reboot request). It
> would be interesting if you could provide the output of the serial
> console when this happens, that might be helpful. Did you enable
> xenconsoled logging?

Unfortunately I did not.

> Also, could you provide more info about your system, Xen version, what
> workload was the DomU running, Dom0 kernel version?

There was no one logged in at the time of the reboot according to the last log.
I did do some sysbench tests during the day, but that was way before it 
rebooted. The only thing that could be running during that time was daily 
periodic.

$ sudo xm info
host   : soleus01.soleus.nu
release: 2.6.32-5-xen-amd64
version: #1 SMP Mon Oct 3 07:53:54 UTC 2011
machine: x86_64
nr_cpus: 8
nr_nodes   : 2
cores_per_socket   : 4
threads_per_core   : 1
cpu_mhz: 2200
hw_caps: 
178bf3ff:efd3fbff::1310:00802001::37ff:
virt_caps  : hvm
total_memory   : 65534
free_memory: 6866
node_to_cpu: node0:0-3
 node1:4-7
node_to_memory : node0:3128
 node1:3737
node_to_dma32_mem  : node0:3128
 node1:0
max_node_id: 1
xen_major  : 4
xen_minor  : 0
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=0x8000
xen_changeset  : unavailable
xen_commandline: placeholder dom0_mem=1852M
cc_compiler: gcc version 4.4.5 (Debian 4.4.5-10)
cc_compile_by  : waldi
cc_compile_domain  : debian.org
cc_compile_date: Wed Jan 12 14:04:06 UTC 2011
xend_config_format : 4

$ uname -a
Linux soleus01.soleus.nu 2.6.32-5-xen-amd64 #1 SMP Mon Oct 3 07:53:54 UTC 2011 
x86_64 GNU/Linux

Jeroen.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

On 30/05/13 10:50, Jeroen van der Ham wrote:
> Hi,
> 
> On 23 May 2013, at 19:41, Roger Pau Monné  wrote:
> 
>> Hello,
>>
>> I've pushed a new branch, pvhvm_v10 that contains a PV IPI
>> implementation for both amd64 and i386. I've also updated the wiki to
>> point to the pvhvm_v10 branch:
> 
> I've been running a VM with this kernel for about a week now. It ran fine, 
> until about 3:30 in the morning. The only thing I can see is the following 
> cryptic messages in /var/log/messages, followed by a reboot of the system.
> 
> May 29 23:42:30 image01 sshd[31227]: error: Received disconnect from 
> 150.165.15.175: 11: Bye Bye [preauth]
> May 30 03:30:57 image01 kernel: .
> May 30 03:30:57 image01 ntpd[4436]: ntpd exiting on signal 15
> May 30 03:30:57 image01 kernel: .
> May 30 03:30:58 image01 kernel: .
> May 30 03:31:00 image01 syslogd: exiting on signal 15
> May 30 03:32:52 image01 syslogd: kernel boot file is /boot/kernel/kernel
> May 30 03:32:52 image01 kernel: Copyright (c) 1992-2013 The FreeBSD Project.
> May 30 03:32:52 image01 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 
> 1989, 1991, 1992, 1993, 1994
> May 30 03:32:52 image01 kernel: The Regents of the University of California. 
> All rights reserved.
> May 30 03:32:52 image01 kernel: FreeBSD is a registered trademark of The 
> FreeBSD Foundation.
> 
> I'm happy to help to gather more information, just tell me what you need.

Hello Jeroen,

So it looks like the system rebooted (but it was not a crash or a
sporadic reboot? the kernel seems to be aware of the reboot request). It
would be interesting if you could provide the output of the serial
console when this happens, that might be helpful. Did you enable
xenconsoled logging?

Also, could you provide more info about your system, Xen version, what
workload was the DomU running, Dom0 kernel version?

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Jeroen van der Ham]

Hi,

On 23 May 2013, at 19:41, Roger Pau Monné  wrote:

> Hello,
> 
> I've pushed a new branch, pvhvm_v10 that contains a PV IPI
> implementation for both amd64 and i386. I've also updated the wiki to
> point to the pvhvm_v10 branch:

I've been running a VM with this kernel for about a week now. It ran fine, 
until about 3:30 in the morning. The only thing I can see is the following 
cryptic messages in /var/log/messages, followed by a reboot of the system.

May 29 23:42:30 image01 sshd[31227]: error: Received disconnect from 
150.165.15.175: 11: Bye Bye [preauth]
May 30 03:30:57 image01 kernel: .
May 30 03:30:57 image01 ntpd[4436]: ntpd exiting on signal 15
May 30 03:30:57 image01 kernel: .
May 30 03:30:58 image01 kernel: .
May 30 03:31:00 image01 syslogd: exiting on signal 15
May 30 03:32:52 image01 syslogd: kernel boot file is /boot/kernel/kernel
May 30 03:32:52 image01 kernel: Copyright (c) 1992-2013 The FreeBSD Project.
May 30 03:32:52 image01 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 
1989, 1991, 1992, 1993, 1994
May 30 03:32:52 image01 kernel: The Regents of the University of California. 
All rights reserved.
May 30 03:32:52 image01 kernel: FreeBSD is a registered trademark of The 
FreeBSD Foundation.

I'm happy to help to gather more information, just tell me what you need.

Jeroen.


___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Justin T. Gibbs]

On May 28, 2013, at 5:20 PM, Outback Dingo  wrote:

> On Tue, May 28, 2013 at 7:09 PM, Craig Rodrigues 
> wrote:
> 
>> On Tue, May 28, 2013 at 3:43 PM, Outback Dingo wrote:
>> 
>>> 
>>> I wrote a blog post specifically for installing 10-CURRENT from a
 snapshot ISO and getting bootstrapped
 from there, to help the Google Summer of Code Student that I am
 mentoring.
 What specifically do you want to be backported to 9-STABLE?
 
>>> 
>>> Yes Ive seen the post, however we have a hard requirement for 9-STABLE
>>> for some development work we are
>>> currently involved in. And I would prefer not to move our current
>>> infrastructure for development to CURRENT.
>>> A major portion of our development environment is based on XEN for
>>> testing and development.
>>> Therefor we realize PVHM is a work in progress, and we have built some
>>> VMs from it, they run exceptionally
>>> well, However our build environments refuse to build 9-STABLE on CURRENT
>>> PVHVM, or 10-CURRENT.
>>> Lastly Im sure theres a ton of users who would like to see this in 9.x or
>>> 9-STABLE
>>> 
>>> 
>> 
>> OK, I misunderstood you since you responded in the thread and quoted some
>> of my post.
>> My blog post has nothing relevant to Xen and PVHM, and is specific to
>> setting up
>> a Google Summer of Code student on a 10-CURRENT environment.  The FreeBSD
>> Xen
>> and PVHM developers will need to provide the details about their plans to
>> merge their changes to the 9-STABLE branch.
>> that's something which I am not familiar with.
>> 
> 
> If we can get a diff of the work done against the master Id be happy to
> help backporting and testing

I plan to backport the work once we have it all in -current.

--
Justin
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Outback Dingo]

On Tue, May 28, 2013 at 7:09 PM, Craig Rodrigues wrote:

>
>
>
> On Tue, May 28, 2013 at 3:43 PM, Outback Dingo wrote:
>
>>
>>  I wrote a blog post specifically for installing 10-CURRENT from a
>>> snapshot ISO and getting bootstrapped
>>> from there, to help the Google Summer of Code Student that I am
>>> mentoring.
>>> What specifically do you want to be backported to 9-STABLE?
>>>
>>
>> Yes Ive seen the post, however we have a hard requirement for 9-STABLE
>> for some development work we are
>> currently involved in. And I would prefer not to move our current
>> infrastructure for development to CURRENT.
>> A major portion of our development environment is based on XEN for
>> testing and development.
>> Therefor we realize PVHM is a work in progress, and we have built some
>>  VMs from it, they run exceptionally
>> well, However our build environments refuse to build 9-STABLE on CURRENT
>> PVHVM, or 10-CURRENT.
>> Lastly Im sure theres a ton of users who would like to see this in 9.x or
>> 9-STABLE
>>
>>
>
> OK, I misunderstood you since you responded in the thread and quoted some
> of my post.
> My blog post has nothing relevant to Xen and PVHM, and is specific to
> setting up
> a Google Summer of Code student on a 10-CURRENT environment.  The FreeBSD
> Xen
> and PVHM developers will need to provide the details about their plans to
> merge their changes to the 9-STABLE branch.
> that's something which I am not familiar with.
>

If we can get a diff of the work done against the master Id be happy to
help backporting and testing


>
>
> --
> Craig
>
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Craig Rodrigues]

On Tue, May 28, 2013 at 3:43 PM, Outback Dingo wrote:

>
> I wrote a blog post specifically for installing 10-CURRENT from a snapshot
>> ISO and getting bootstrapped
>> from there, to help the Google Summer of Code Student that I am mentoring.
>> What specifically do you want to be backported to 9-STABLE?
>>
>
> Yes Ive seen the post, however we have a hard requirement for 9-STABLE for
> some development work we are
> currently involved in. And I would prefer not to move our current
> infrastructure for development to CURRENT.
> A major portion of our development environment is based on XEN for testing
> and development.
> Therefor we realize PVHM is a work in progress, and we have built some
>  VMs from it, they run exceptionally
> well, However our build environments refuse to build 9-STABLE on CURRENT
> PVHVM, or 10-CURRENT.
> Lastly Im sure theres a ton of users who would like to see this in 9.x or
> 9-STABLE
>
>

OK, I misunderstood you since you responded in the thread and quoted some
of my post.
My blog post has nothing relevant to Xen and PVHM, and is specific to
setting up
a Google Summer of Code student on a 10-CURRENT environment.  The FreeBSD
Xen
and PVHM developers will need to provide the details about their plans to
merge their changes to the 9-STABLE branch.
that's something which I am not familiar with.

-- 
Craig
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Outback Dingo]

On Tue, May 28, 2013 at 6:05 PM, Craig Rodrigues wrote:

>
>
>
> On Tue, May 28, 2013 at 8:21 AM, Outback Dingo wrote:
>
>>
>>
>>
>> On Fri, May 24, 2013 at 6:27 PM, Craig Rodrigues 
>> wrote:
>>
>>> I wrote this blog post:
>>>
>>>
>>> http://blogs.freebsdish.org/rodrigc/2013/05/24/setting-up-a-vm-for-doing-gsoc-work/
>>>
>>> for the steps how to do it.  You can follow those steps to get
>>> bootstrapped
>>> with a working environment if it helps you out.
>>>
>>> Good luck.
>>>
>>>
>> Any chance this will be backported to 9.X or 9-STABLE at least ??
>>
>>
>
>
> I wrote a blog post specifically for installing 10-CURRENT from a snapshot
> ISO and getting bootstrapped
> from there, to help the Google Summer of Code Student that I am mentoring.
> What specifically do you want to be backported to 9-STABLE?
>

Yes Ive seen the post, however we have a hard requirement for 9-STABLE for
some development work we are
currently involved in. And I would prefer not to move our current
infrastructure for development to CURRENT.
A major portion of our development environment is based on XEN for testing
and development.
Therefor we realize PVHVM is a work in progress, and we have built some
 VMs from it, they run exceptionally
well, However our build environments refuse to build 9-STABLE on CURRENT
PVHVM, or 10-CURRENT.
Lastly Im sure theres a ton of users who would like to see this in 9.x or
9-STABLE



>
>
> --
> Craig
>
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Craig Rodrigues]

On Tue, May 28, 2013 at 8:21 AM, Outback Dingo wrote:

>
>
>
> On Fri, May 24, 2013 at 6:27 PM, Craig Rodrigues 
> wrote:
>
>> I wrote this blog post:
>>
>>
>> http://blogs.freebsdish.org/rodrigc/2013/05/24/setting-up-a-vm-for-doing-gsoc-work/
>>
>> for the steps how to do it.  You can follow those steps to get
>> bootstrapped
>> with a working environment if it helps you out.
>>
>> Good luck.
>>
>>
> Any chance this will be backported to 9.X or 9-STABLE at least ??
>
>


I wrote a blog post specifically for installing 10-CURRENT from a snapshot
ISO and getting bootstrapped
from there, to help the Google Summer of Code Student that I am mentoring.
What specifically do you want to be backported to 9-STABLE?

-- 
Craig
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

On 24/05/13 12:11, Roger Pau Monné wrote:
> On 23/05/13 21:09, Colin Percival wrote:
>> On 05/23/13 02:06, Roger Pau Monné wrote:
>>> On 22/05/13 22:03, Colin Percival wrote:
 Testing on a cr1.8xlarge EC2 instance, I get Xen 4.2, but it ends up with
 a panic -- console output below.  I can get a backtrace and possibly even
 a dump if those would help.
>>>
>>> Thanks for the test, I've been using Xen 4.2 (and 4.3) without problems 
>>> so far. By looking at the Xen code, the only reason the timer setup 
>>> could return -22 (EINVAL), is that we try to set the timer for a 
>>> different vCPU than the one we are running on.
>>>
>>> I've been able to boot a 32 vCPU DomU on my 8way box using Xen 4.2.1 
>>> (using both qemu-xen and qemu-xen-traditional device models), so I'm 
>>> unsure if this could be due to some patch Amazon applies to Xen. Could 
>>> you try the following patch and post the error message? I would like to 
>>> see if the cpuid reported by kdb and the vCPU that we are trying to set 
>>> the timer are the same.
>>
>> Looks like there's agreement about the cpuids here.  Anything else I should
>> try testing?
> 
> Thanks for the test, this is what I expected. I'm a little bit out of
> ideas since I'm not able to reproduce this on upstream Xen 4.2. Without
> knowing what's happening inside the hypervisor it's hard to tell what's
> wrong. It would be interesting to try if the same happens with a Linux
> PVHVM (not PV) running on the same instance type.

Hello Matt,

Colin has found an issue on the FreeBSD PVHVM port that I haven't been
able to reproduce using open source Xen, even when using the same
version as the one reported by EC2. Is there anyway you could provide
some help debugging this? Without seeing the Xen code that causes
VCPUOP_set_singleshot_timer to return EINVAL it is quite hard to figure
out what's happening inside the hypervisor.

Thanks, Roger.
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Outback Dingo]

On Fri, May 24, 2013 at 6:27 PM, Craig Rodrigues wrote:

> On Thu, May 23, 2013 at 6:30 AM, Roger Pau Monné  >wrote:
>
> > On 23/05/13 15:20, Jeroen van der Ham wrote:
> > >
> > > On 13 May 2013, at 20:32, Roger Pau Monné 
> wrote:
> > >> Also, I've created a wiki page that explains how to set up a FreeBSD
> > >> PVHVM for testing:
> > >>
> > >> http://wiki.xen.org/wiki/Testing_FreeBSD_PVHVM
> > >
> > >
> > > You mention on that page that it is easier to install on 10.0-CURRENT
> > snapshots.
> > > What are the issues with installing this on 9.1? Is it possible?
> >
> > I don't think it is recommended to use a HEAD (10) kernel with a 9.1
> > userland. You can always install a 9.1 and then do a full update with
> > the source on my repository.
> >
>
>
> Actually in FreeBSD, it is possible to run an older userland on a newer
> kernel,
> and a lot of effort is spent in preserving this type of backwards
> compatibility.
> So a 9.1 userland with a 10 kernel will work.
> However, running a newer userland on an older kernel is not guaranteed to
> work.
> So running a 10 userland with a 9.1 kernel will most likely not work.
>
> However, since you guys are doing very cutting edge stuff with 10-CURRENT,
> it is better that you do not waste time with 9.1.
>
> I recommend you start with a 10.0 CURRENT snapshot ISO and go from there.
> I am going through a similar setup exercise with a Google Summer of Code
> student
> where he needs to have a latest CURRENT system running in a VM.
>
> I wrote this blog post:
>
>
> http://blogs.freebsdish.org/rodrigc/2013/05/24/setting-up-a-vm-for-doing-gsoc-work/
>
> for the steps how to do it.  You can follow those steps to get bootstrapped
> with a working environment if it helps you out.
>
> Good luck.
>
>
Any chance this will be backported to 9.X or 9-STABLE at least ??


> --
> Craig
> ___
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-xen
> To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
>
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Craig Rodrigues]

On Thu, May 23, 2013 at 6:30 AM, Roger Pau Monné wrote:

> On 23/05/13 15:20, Jeroen van der Ham wrote:
> >
> > On 13 May 2013, at 20:32, Roger Pau Monné  wrote:
> >> Also, I've created a wiki page that explains how to set up a FreeBSD
> >> PVHVM for testing:
> >>
> >> http://wiki.xen.org/wiki/Testing_FreeBSD_PVHVM
> >
> >
> > You mention on that page that it is easier to install on 10.0-CURRENT
> snapshots.
> > What are the issues with installing this on 9.1? Is it possible?
>
> I don't think it is recommended to use a HEAD (10) kernel with a 9.1
> userland. You can always install a 9.1 and then do a full update with
> the source on my repository.
>


Actually in FreeBSD, it is possible to run an older userland on a newer
kernel,
and a lot of effort is spent in preserving this type of backwards
compatibility.
So a 9.1 userland with a 10 kernel will work.
However, running a newer userland on an older kernel is not guaranteed to
work.
So running a 10 userland with a 9.1 kernel will most likely not work.

However, since you guys are doing very cutting edge stuff with 10-CURRENT,
it is better that you do not waste time with 9.1.

I recommend you start with a 10.0 CURRENT snapshot ISO and go from there.
I am going through a similar setup exercise with a Google Summer of Code
student
where he needs to have a latest CURRENT system running in a VM.

I wrote this blog post:

http://blogs.freebsdish.org/rodrigc/2013/05/24/setting-up-a-vm-for-doing-gsoc-work/

for the steps how to do it.  You can follow those steps to get bootstrapped
with a working environment if it helps you out.

Good luck.

-- 
Craig
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

On 23/05/13 21:09, Colin Percival wrote:
> On 05/23/13 02:06, Roger Pau Monné wrote:
>> On 22/05/13 22:03, Colin Percival wrote:
>>> Testing on a cr1.8xlarge EC2 instance, I get Xen 4.2, but it ends up with
>>> a panic -- console output below.  I can get a backtrace and possibly even
>>> a dump if those would help.
>>
>> Thanks for the test, I've been using Xen 4.2 (and 4.3) without problems 
>> so far. By looking at the Xen code, the only reason the timer setup 
>> could return -22 (EINVAL), is that we try to set the timer for a 
>> different vCPU than the one we are running on.
>>
>> I've been able to boot a 32 vCPU DomU on my 8way box using Xen 4.2.1 
>> (using both qemu-xen and qemu-xen-traditional device models), so I'm 
>> unsure if this could be due to some patch Amazon applies to Xen. Could 
>> you try the following patch and post the error message? I would like to 
>> see if the cpuid reported by kdb and the vCPU that we are trying to set 
>> the timer are the same.
> 
> Looks like there's agreement about the cpuids here.  Anything else I should
> try testing?

Thanks for the test, this is what I expected. I'm a little bit out of
ideas since I'm not able to reproduce this on upstream Xen 4.2. Without
knowing what's happening inside the hypervisor it's hard to tell what's
wrong. It would be interesting to try if the same happens with a Linux
PVHVM (not PV) running on the same instance type.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Yuriy Kohut]

Hi,

I've just successfully run FreeBSD 9.1 based guest with 'pvhvm_v8' based kernel 
under Xen 4.2.2.

So I couldn't confirm any issue with the kernel both on Xen 3.4.4 and 4.2.2.
Nice Job.

Hypervisor details:
# xm info
host   : 
release: 3.8.7-1.el6xen
version: #1 SMP Tue Apr 16 13:14:14 EEST 2013
machine: x86_64
nr_cpus: 4
nr_nodes   : 1
cores_per_socket   : 4
threads_per_core   : 1
cpu_mhz: 1995
hw_caps: 
bfebfbff:28100800::3b40:009ce3bd::0001:
virt_caps  : hvm
total_memory   : 16374
free_memory: 7194
free_cpus  : 0
xen_major  : 4
xen_minor  : 2
xen_extra  : .2
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=0x8000
xen_changeset  : unavailable
xen_commandline: dom0_mem=409600
cc_compiler: gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3)
cc_compile_by  : mockbuild
cc_compile_domain  : 
cc_compile_date: Tue May  7 19:26:49 EST 2013
xend_config_format : 4


DomU details:
# xm list --long f2tbrxodmgk9ng
(domain
(domid 146)
(cpu_weight 400)
(cpu_cap 0)
(pool_name Pool-0)
(bootloader '')
(vcpus 4)
(cpus (() () () ()))
(on_poweroff destroy)
(description '')
(on_crash restart)
(uuid 355cfb26-4793-f85a-e330-7b6bfcae49b5)
(bootloader_args '')
(name f2tbrxodmgk9ng)
(on_reboot restart)
(maxmem 1024)
(memory 1024)
(shadow_memory 12)
(features '')
(on_xend_start ignore)
(on_xend_stop ignore)
(start_time 1369384081.34)
(cpu_time 59.956655605)
(online_vcpus 4)
(image
(hvm
(kernel '')
(superpages 0)
(videoram 4)
(hpet 0)
(stdvga 0)
(loader /usr/lib/xen/boot/hvmloader)
(xen_platform_pci 1)
(nestedhvm 0)
(rtc_timeoffset 10801)
(pci ())
(hap 1)
(localtime 0)
(timer_mode 1)
(pci_msitranslate 1)
(oos 1)
(apic 1)
(usbdevice tablet)
(vpt_align 1)
(vncunused 1)
(boot cd)
(pae 1)
(viridian 0)
(acpi 1)
(vnc 1)
(nographic 0)
(nomigrate 0)
(usb 0)
(tsc_mode 0)
(guest_os_type default)
(device_model /usr/lib64/xen/bin/qemu-dm)
(pci_power_mgmt 0)
(xauthority /root/.Xauthority)
(isa 0)
(notes (SUSPEND_CANCEL 1))
)
)
(status 2)
(state -b)
(store_mfn 1044476)
(device
(vif
(bridge nnl9l2z5l3q3d8)
(uuid daeabd68-05a0-f25b-ba65-394627505b50)
(script /etc/xen/scripts/vif-bridge)
(ip 109.123.91.166)
(mac 00:16:3e:e8:88:49)
(vifname qgdvmt5h6d2l9s)
(backend 0)
)
)
(device
(console
(protocol vt100)
(location 7)
(uuid c670a71d-4c3b-1fcb-974a-587f17740a6c)
)
)
(device
(vbd
(protocol x86_64-abi)
(uuid 9067929c-9b48-99c6-5526-e771d43f427c)
(bootable 1)
(dev hda:disk)
(uname phy:/dev/fv4zl7t2h5wbeq/o76ciuubu0r986)
(mode w)
(backend 0)
(VDI '')
)
)
(device
(vbd
(protocol x86_64-abi)
(uuid 2ae3630e-0e8e-04e4-8caf-ac4d1e9fd402)
(bootable 0)
(dev hdb:disk)
(uname phy:/dev/fv4zl7t2h5wbeq/xi0nw7u4zo0bu9)
(mode w)
(backend 0)
(VDI '')
)
)
(device
(vbd
(protocol x86_64-abi)
(uuid 33d3e25c-0c1c-ced6-c8b6-5a706ab0d403)
(bootable 0)
(dev hdc:cdrom)
(uname file:/tools/freebsd/boot-freebsd-generic.iso)
(mode r)
(backend 0)
(VDI '')
)
)
(device
(vfb
(vncunused 1)
(vnc 1)
(uuid 438a2ffd-bec7-1e54-bb0b-4fdd400517cf)
(location 0.0.0.0:5908)
)
)
)



DomU from "inside":
# uname -a
FreeBSD yurak2.vm 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r+03cdadc: Thu May 23 
18:55:33 AST 2013 r...@yurak2.vm:/usr/obj/freebsd/sys/XENHVM  amd64
---
Yura

On May 22, 2013, at 18:27 PM, Yuriy Kohut  wrote:

> Hi,
> 
> I've just successfully run FreeBSD 9.1 based guest with 'pvhvm_v8' based 
> kernel under Xen 3.4.4.
> 
> Hypervisor details:
> # xm info
> host   : ***
> release

Re: FreeBSD PVHVM call for testing

[Outback Dingo]

On Mon, May 13, 2013 at 2:32 PM, Roger Pau Monné wrote:

> Hello,
>
> Recently Justin T Gibbs, Will Andrews and myself have been working on
> improving the Xen support in FreeBSD. The main goal of this was to bring
> full PVHVM support to FreeBSD, right now FreeBSD is only using PV
> interfaces for disk and network interfaces when running as a HVM guest.
> The main benefits of this changes are that Xen virtual interrupts (event
> channels) are now delivered to the guest using a vector callback
> injection, that is a per-cpu mechanism that allows each vCPU to have
> different interrupts assigned, so for example network and disk
> interrupts are delivered to different vCPUs in order to improve
> performance. With this changes FreeBSD also uses PV timers when running
> as an HVM guest, which should provide better time keeping and reduce the
> virtualization overhead, since emulated timers are no longer used. PV
> IPIs can also be used inside a HVM guest, but this will be implemented
> later.
>
> Right now the code is in a state where it can be tested by users, so we
> would like to encourage FreeBSD and Xen users to test it and provide
> feedback.
>
> The code is available in the following git repository, under the branch
> pvhvm_v5:
>
> http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=summary
>
> Also, I've created a wiki page that explains how to set up a FreeBSD
> PVHVM for testing:
>
> http://wiki.xen.org/wiki/Testing_FreeBSD_PVHVM



Hey Guys,

Huge KUDOS to some great work, Ive gotten 4 VMs booting from zfsonroot with
the rev_9 finally under XCP 1.6
after getting through removal of the cdrom device from VMs, they are booted
and running supremely nice now.
IO for zfs filesystems is much better inside the VMs now, even with 4mb
compared to what it was. This is a huge
move forward and personally I just wanted to say thanks for this and all
the work you put into it. The VMs appear quite stable for me, and are
pleasantly responsive with low mem on zpools. Great job and again.
Thanks. Keep up the great effort.


>
> ___
> freebsd-virtualization@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to "
> freebsd-virtualization-unsubscr...@freebsd.org"
>
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

Hello,

I've pushed a new branch, pvhvm_v10 that contains a PV IPI
implementation for both amd64 and i386. I've also updated the wiki to
point to the pvhvm_v10 branch:

http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvhvm_v10

I've updated my tree to latest HEAD, so now branch pvhvm_v10 is on top
of this commit:

commit b44da0fb82647f2cfb06f65a6695c7e36c98828c
Author: gber 
Date:   Thu May 23 12:24:46 2013 +

Rework and organize pmap_enter_locked() function.

pmap_enter_locked() implementation was very ambiguous and confusing.
Rearrange it so that each part of the mapping creation is separated.
Avoid walking through the redundant conditions.
Extract vector_page specific PTE setup from normal PTE setting.

Submitted by:   Zbigniew Bodek 
Sponsored by:   The FreeBSD Foundation, Semihalf

Thanks for the testing, Roger.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Outback Dingo]

On Thu, May 23, 2013 at 1:22 PM, Jeroen van der Ham  wrote:

> Hi,
>
> Just remove this line (or pointing to a similar file from the template:
> (It's part of the disks definition:
>
> >   'file:/root/freebsd-10.iso,hdc:cdrom,r',
>
>
Thanks, but this is XCP not a generic XEN server where there are vm config
files under /etc/xen/ in XCP they dont exists


> Jeroen.
>
> On 23 May 2013, at 19:02, Outback Dingo  wrote:
>
> > On Thu, May 23, 2013 at 12:48 PM, Roger Pau Monné  >wrote:
> >
> >> On 23/05/13 18:30, Outback Dingo wrote:
> >>>
> >>>
> >>>
> >>> On Thu, May 23, 2013 at 9:33 AM, Roger Pau Monné  >>> > wrote:
> >>>
> >>>On 23/05/13 14:57, Jeroen van der Ham wrote:
>  Hi,
> 
>  On 13 May 2013, at 20:32, Roger Pau Monné  >>>> wrote:
> > Right now the code is in a state where it can be tested by users,
> >>>so we
> > would like to encourage FreeBSD and Xen users to test it and
> >> provide
> > feedback.
> 
>  I've just been able to install it on a VPS using the latest
> >>>pvhvm_v9 branch.
> >>>
> >>>The branch pvhvm_v9 contains an initial implementation of PV IPIs
> for
> >>>amd64. I've now finished it and I'm going to port it to i386 also,
> >> and
> >>>push a new branch to the repository.
> >>>
>  This is good news, because the system I had before actually had
> >>>trouble with the HVM kernel from 9.1 [0].
> 
>  I'm going to leave this running for a while and do some more tests
> >>>on it.
> 
>  Jeroen.
> 
> 
>  [0]: http://www.freebsd.org/cgi/query-pr.cgi?pr=175822
> 
> >>>
> >>> I built the rev_9 branch on a XCP host and rebooted, however I am
> seeing
> >>>
> >>> on boot after ugen0.2:  at usbus0
> >>>
> >>> run_interrupt_driven_hooks: still waiting after 60 seconds for
> >>> xenbus_nop_confighook_cb
> >>> run_interrupt_driven_hooks: still waiting after 120 seconds for
> >>> xenbus_nop_confighook_cb
> >>> run_interrupt_driven_hooks: still waiting after 180 seconds for
> >>> xenbus_nop_confighook_cb
> >>> run_interrupt_driven_hooks: still waiting after 240 seconds for
> >>> xenbus_nop_confighook_cb
> >>> run_interrupt_driven_hooks: still waiting after 300 seconds for
> >>> xenbus_nop_confighook_cb
> >>> panic: run_interrupt_driven_confighooks: waited too long
> >>> cpuid = 0
> >>> KDB: enter: panic
> >>> [ thread pid 0 tid 10 ]
> >>> Stropped at kdb_enter +0x3b: movq $0,0xad6522(%rip)
> >>> db>
> >>
> >> From what I've read on the list, it seems like you cannot boot the PVHVM
> >> kernel if you have a cdrom attached to the guest, could you try
> >> disabling the cdrom and booting again?
> >>
> >>
> > great how does one go about disabling the cdrom, i get some disk
> parameters
> > needs to be removed from the vm template before boot
>
>
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Jeroen van der Ham]

Hi,

Just remove this line (or pointing to a similar file from the template: (It's 
part of the disks definition:

>   'file:/root/freebsd-10.iso,hdc:cdrom,r',

Jeroen.

On 23 May 2013, at 19:02, Outback Dingo  wrote:

> On Thu, May 23, 2013 at 12:48 PM, Roger Pau Monné wrote:
> 
>> On 23/05/13 18:30, Outback Dingo wrote:
>>> 
>>> 
>>> 
>>> On Thu, May 23, 2013 at 9:33 AM, Roger Pau Monné >> > wrote:
>>> 
>>>On 23/05/13 14:57, Jeroen van der Ham wrote:
 Hi,
 
 On 13 May 2013, at 20:32, Roger Pau Monné >>> wrote:
> Right now the code is in a state where it can be tested by users,
>>>so we
> would like to encourage FreeBSD and Xen users to test it and
>> provide
> feedback.
 
 I've just been able to install it on a VPS using the latest
>>>pvhvm_v9 branch.
>>> 
>>>The branch pvhvm_v9 contains an initial implementation of PV IPIs for
>>>amd64. I've now finished it and I'm going to port it to i386 also,
>> and
>>>push a new branch to the repository.
>>> 
 This is good news, because the system I had before actually had
>>>trouble with the HVM kernel from 9.1 [0].
 
 I'm going to leave this running for a while and do some more tests
>>>on it.
 
 Jeroen.
 
 
 [0]: http://www.freebsd.org/cgi/query-pr.cgi?pr=175822
 
>>> 
>>> I built the rev_9 branch on a XCP host and rebooted, however I am seeing
>>> 
>>> on boot after ugen0.2:  at usbus0
>>> 
>>> run_interrupt_driven_hooks: still waiting after 60 seconds for
>>> xenbus_nop_confighook_cb
>>> run_interrupt_driven_hooks: still waiting after 120 seconds for
>>> xenbus_nop_confighook_cb
>>> run_interrupt_driven_hooks: still waiting after 180 seconds for
>>> xenbus_nop_confighook_cb
>>> run_interrupt_driven_hooks: still waiting after 240 seconds for
>>> xenbus_nop_confighook_cb
>>> run_interrupt_driven_hooks: still waiting after 300 seconds for
>>> xenbus_nop_confighook_cb
>>> panic: run_interrupt_driven_confighooks: waited too long
>>> cpuid = 0
>>> KDB: enter: panic
>>> [ thread pid 0 tid 10 ]
>>> Stropped at kdb_enter +0x3b: movq $0,0xad6522(%rip)
>>> db>
>> 
>> From what I've read on the list, it seems like you cannot boot the PVHVM
>> kernel if you have a cdrom attached to the guest, could you try
>> disabling the cdrom and booting again?
>> 
>> 
> great how does one go about disabling the cdrom, i get some disk parameters
> needs to be removed from the vm template before boot

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Outback Dingo]

On Thu, May 23, 2013 at 12:48 PM, Roger Pau Monné wrote:

> On 23/05/13 18:30, Outback Dingo wrote:
> >
> >
> >
> > On Thu, May 23, 2013 at 9:33 AM, Roger Pau Monné  > > wrote:
> >
> > On 23/05/13 14:57, Jeroen van der Ham wrote:
> > > Hi,
> > >
> > > On 13 May 2013, at 20:32, Roger Pau Monné  > > wrote:
> > >> Right now the code is in a state where it can be tested by users,
> > so we
> > >> would like to encourage FreeBSD and Xen users to test it and
> provide
> > >> feedback.
> > >
> > > I've just been able to install it on a VPS using the latest
> > pvhvm_v9 branch.
> >
> > The branch pvhvm_v9 contains an initial implementation of PV IPIs for
> > amd64. I've now finished it and I'm going to port it to i386 also,
> and
> > push a new branch to the repository.
> >
> > > This is good news, because the system I had before actually had
> > trouble with the HVM kernel from 9.1 [0].
> > >
> > > I'm going to leave this running for a while and do some more tests
> > on it.
> > >
> > > Jeroen.
> > >
> > >
> > > [0]: http://www.freebsd.org/cgi/query-pr.cgi?pr=175822
> > >
> >
> > I built the rev_9 branch on a XCP host and rebooted, however I am seeing
> >
> > on boot after ugen0.2:  at usbus0
> >
> > run_interrupt_driven_hooks: still waiting after 60 seconds for
> > xenbus_nop_confighook_cb
> > run_interrupt_driven_hooks: still waiting after 120 seconds for
> > xenbus_nop_confighook_cb
> > run_interrupt_driven_hooks: still waiting after 180 seconds for
> > xenbus_nop_confighook_cb
> > run_interrupt_driven_hooks: still waiting after 240 seconds for
> > xenbus_nop_confighook_cb
> > run_interrupt_driven_hooks: still waiting after 300 seconds for
> > xenbus_nop_confighook_cb
> > panic: run_interrupt_driven_confighooks: waited too long
> > cpuid = 0
> > KDB: enter: panic
> > [ thread pid 0 tid 10 ]
> > Stropped at kdb_enter +0x3b: movq $0,0xad6522(%rip)
> > db>
>
> From what I've read on the list, it seems like you cannot boot the PVHVM
> kernel if you have a cdrom attached to the guest, could you try
> disabling the cdrom and booting again?
>
>
great how does one go about disabling the cdrom, i get some disk parameters
needs to be removed from the vm template before boot
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

On 23/05/13 18:30, Outback Dingo wrote:
> 
> 
> 
> On Thu, May 23, 2013 at 9:33 AM, Roger Pau Monné  > wrote:
> 
> On 23/05/13 14:57, Jeroen van der Ham wrote:
> > Hi,
> >
> > On 13 May 2013, at 20:32, Roger Pau Monné  > wrote:
> >> Right now the code is in a state where it can be tested by users,
> so we
> >> would like to encourage FreeBSD and Xen users to test it and provide
> >> feedback.
> >
> > I've just been able to install it on a VPS using the latest
> pvhvm_v9 branch.
> 
> The branch pvhvm_v9 contains an initial implementation of PV IPIs for
> amd64. I've now finished it and I'm going to port it to i386 also, and
> push a new branch to the repository.
> 
> > This is good news, because the system I had before actually had
> trouble with the HVM kernel from 9.1 [0].
> >
> > I'm going to leave this running for a while and do some more tests
> on it.
> >
> > Jeroen.
> >
> >
> > [0]: http://www.freebsd.org/cgi/query-pr.cgi?pr=175822
> >
> 
> I built the rev_9 branch on a XCP host and rebooted, however I am seeing
> 
> on boot after ugen0.2:  at usbus0
> 
> run_interrupt_driven_hooks: still waiting after 60 seconds for
> xenbus_nop_confighook_cb
> run_interrupt_driven_hooks: still waiting after 120 seconds for
> xenbus_nop_confighook_cb
> run_interrupt_driven_hooks: still waiting after 180 seconds for
> xenbus_nop_confighook_cb
> run_interrupt_driven_hooks: still waiting after 240 seconds for
> xenbus_nop_confighook_cb
> run_interrupt_driven_hooks: still waiting after 300 seconds for
> xenbus_nop_confighook_cb
> panic: run_interrupt_driven_confighooks: waited too long
> cpuid = 0
> KDB: enter: panic
> [ thread pid 0 tid 10 ]
> Stropped at kdb_enter +0x3b: movq $0,0xad6522(%rip)
> db>

>From what I've read on the list, it seems like you cannot boot the PVHVM
kernel if you have a cdrom attached to the guest, could you try
disabling the cdrom and booting again?

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Sergey Kandaurov]

On 23 May 2013 20:30, Outback Dingo  wrote:
> On Thu, May 23, 2013 at 9:33 AM, Roger Pau Monné wrote:
>
>> On 23/05/13 14:57, Jeroen van der Ham wrote:
>> > Hi,
>> >
>> > On 13 May 2013, at 20:32, Roger Pau Monné  wrote:
>> >> Right now the code is in a state where it can be tested by users, so we
>> >> would like to encourage FreeBSD and Xen users to test it and provide
>> >> feedback.
>> >
>> > I've just been able to install it on a VPS using the latest pvhvm_v9
>> branch.
>>
>> The branch pvhvm_v9 contains an initial implementation of PV IPIs for
>> amd64. I've now finished it and I'm going to port it to i386 also, and
>> push a new branch to the repository.
>>
>> > This is good news, because the system I had before actually had trouble
>> with the HVM kernel from 9.1 [0].
>> >
>> > I'm going to leave this running for a while and do some more tests on it.
>> >
>> > Jeroen.
>> >
>> >
>> > [0]: http://www.freebsd.org/cgi/query-pr.cgi?pr=175822
>> >
>>
>> I built the rev_9 branch on a XCP host and rebooted, however I am seeing
>
> on boot after ugen0.2:  at usbus0
>
> run_interrupt_driven_hooks: still waiting after 60 seconds for
> xenbus_nop_confighook_cb
> run_interrupt_driven_hooks: still waiting after 120 seconds for
> xenbus_nop_confighook_cb
> run_interrupt_driven_hooks: still waiting after 180 seconds for
> xenbus_nop_confighook_cb
> run_interrupt_driven_hooks: still waiting after 240 seconds for
> xenbus_nop_confighook_cb
> run_interrupt_driven_hooks: still waiting after 300 seconds for
> xenbus_nop_confighook_cb
> panic: run_interrupt_driven_confighooks: waited too long
> cpuid = 0
> KDB: enter: panic
> [ thread pid 0 tid 10 ]
> Stropped at kdb_enter +0x3b: movq $0,0xad6522(%rip)
> db>

Can you recheck this on stock HEAD?

>From your description this looks like a rather old bug seen with 8.2
or above and XCP (referenced in PR kern/164630). You can trigger it
when e.g. booting with empty cdrom.

-- 
wbr,
pluknet
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Outback Dingo]

On Thu, May 23, 2013 at 9:33 AM, Roger Pau Monné wrote:

> On 23/05/13 14:57, Jeroen van der Ham wrote:
> > Hi,
> >
> > On 13 May 2013, at 20:32, Roger Pau Monné  wrote:
> >> Right now the code is in a state where it can be tested by users, so we
> >> would like to encourage FreeBSD and Xen users to test it and provide
> >> feedback.
> >
> > I've just been able to install it on a VPS using the latest pvhvm_v9
> branch.
>
> The branch pvhvm_v9 contains an initial implementation of PV IPIs for
> amd64. I've now finished it and I'm going to port it to i386 also, and
> push a new branch to the repository.
>
> > This is good news, because the system I had before actually had trouble
> with the HVM kernel from 9.1 [0].
> >
> > I'm going to leave this running for a while and do some more tests on it.
> >
> > Jeroen.
> >
> >
> > [0]: http://www.freebsd.org/cgi/query-pr.cgi?pr=175822
> >
>
> I built the rev_9 branch on a XCP host and rebooted, however I am seeing

on boot after ugen0.2:  at usbus0

run_interrupt_driven_hooks: still waiting after 60 seconds for
xenbus_nop_confighook_cb
run_interrupt_driven_hooks: still waiting after 120 seconds for
xenbus_nop_confighook_cb
run_interrupt_driven_hooks: still waiting after 180 seconds for
xenbus_nop_confighook_cb
run_interrupt_driven_hooks: still waiting after 240 seconds for
xenbus_nop_confighook_cb
run_interrupt_driven_hooks: still waiting after 300 seconds for
xenbus_nop_confighook_cb
panic: run_interrupt_driven_confighooks: waited too long
cpuid = 0
KDB: enter: panic
[ thread pid 0 tid 10 ]
Stropped at kdb_enter +0x3b: movq $0,0xad6522(%rip)
db>



___
> freebsd-virtualization@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to "
> freebsd-virtualization-unsubscr...@freebsd.org"
>
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Outback Dingo]

On Thu, May 23, 2013 at 9:33 AM, Roger Pau Monné wrote:

> On 23/05/13 14:57, Jeroen van der Ham wrote:
> > Hi,
> >
> > On 13 May 2013, at 20:32, Roger Pau Monné  wrote:
> >> Right now the code is in a state where it can be tested by users, so we
> >> would like to encourage FreeBSD and Xen users to test it and provide
> >> feedback.
> >
> > I've just been able to install it on a VPS using the latest pvhvm_v9
> branch.
>
> The branch pvhvm_v9 contains an initial implementation of PV IPIs for
> amd64. I've now finished it and I'm going to port it to i386 also, and
> push a new branch to the repository.
>


curious as the from what rev you guys forked your XENPVM work from HEAD, so
i can assure
Ive not lost some fixes, new commits from upstream


>
> > This is good news, because the system I had before actually had trouble
> with the HVM kernel from 9.1 [0].
> >
> > I'm going to leave this running for a while and do some more tests on it.
> >
> > Jeroen.
> >
> >
> > [0]: http://www.freebsd.org/cgi/query-pr.cgi?pr=175822
> >
>
> ___
> freebsd-virtualization@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to "
> freebsd-virtualization-unsubscr...@freebsd.org"
>
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

On 23/05/13 14:57, Jeroen van der Ham wrote:
> Hi,
> 
> On 13 May 2013, at 20:32, Roger Pau Monné  wrote:
>> Right now the code is in a state where it can be tested by users, so we
>> would like to encourage FreeBSD and Xen users to test it and provide
>> feedback.
> 
> I've just been able to install it on a VPS using the latest pvhvm_v9 branch.

The branch pvhvm_v9 contains an initial implementation of PV IPIs for
amd64. I've now finished it and I'm going to port it to i386 also, and
push a new branch to the repository.

> This is good news, because the system I had before actually had trouble with 
> the HVM kernel from 9.1 [0].
> 
> I'm going to leave this running for a while and do some more tests on it.
> 
> Jeroen.
> 
> 
> [0]: http://www.freebsd.org/cgi/query-pr.cgi?pr=175822
> 

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

On 23/05/13 15:20, Jeroen van der Ham wrote:
> 
> On 13 May 2013, at 20:32, Roger Pau Monné  wrote:
>> Also, I've created a wiki page that explains how to set up a FreeBSD
>> PVHVM for testing:
>>
>> http://wiki.xen.org/wiki/Testing_FreeBSD_PVHVM
> 
> 
> You mention on that page that it is easier to install on 10.0-CURRENT 
> snapshots.
> What are the issues with installing this on 9.1? Is it possible?

I don't think it is recommended to use a HEAD (10) kernel with a 9.1
userland. You can always install a 9.1 and then do a full update with
the source on my repository.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Jeroen van der Ham]

On 13 May 2013, at 20:32, Roger Pau Monné  wrote:
> Also, I've created a wiki page that explains how to set up a FreeBSD
> PVHVM for testing:
> 
> http://wiki.xen.org/wiki/Testing_FreeBSD_PVHVM


You mention on that page that it is easier to install on 10.0-CURRENT snapshots.
What are the issues with installing this on 9.1? Is it possible?

Jeroen.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Outback Dingo]

On Thu, May 23, 2013 at 8:57 AM, Jeroen van der Ham  wrote:

> Hi,
>
> On 13 May 2013, at 20:32, Roger Pau Monné  wrote:
> > Right now the code is in a state where it can be tested by users, so we
> > would like to encourage FreeBSD and Xen users to test it and provide
> > feedback.
>
> I've just been able to install it on a VPS using the latest pvhvm_v9
> branch.
> This is good news, because the system I had before actually had trouble
> with the HVM kernel from 9.1 [0].
>
> I'm going to leave this running for a while and do some more tests on it.
>
> Jeroen.
>

Curious if this would work under XEN XCP (Xen Cloud Platform)



>
> [0]: http://www.freebsd.org/cgi/query-pr.cgi?pr=175822
>
> ___
> freebsd-virtualization@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to "
> freebsd-virtualization-unsubscr...@freebsd.org"
>
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Jeroen van der Ham]

Hi,

On 13 May 2013, at 20:32, Roger Pau Monné  wrote:
> Right now the code is in a state where it can be tested by users, so we
> would like to encourage FreeBSD and Xen users to test it and provide
> feedback.

I've just been able to install it on a VPS using the latest pvhvm_v9 branch.
This is good news, because the system I had before actually had trouble with 
the HVM kernel from 9.1 [0].

I'm going to leave this running for a while and do some more tests on it.

Jeroen.


[0]: http://www.freebsd.org/cgi/query-pr.cgi?pr=175822

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

On 22/05/13 22:03, Colin Percival wrote:
> On 05/22/13 04:45, Roger Pau Monné wrote:
>> On 18/05/13 17:44, Colin Percival wrote:
>>> That seems to work.  dmesg is attached.  Are there any particular tests
>>> you'd like me to run?
>>
>> I have not tested ZFS, that might be a good one. If you are running this
>> on Xen 3.4 the behaviour should be the same as without this patches, so
>> there shouldn't be many differences.
> 
> I don't use ZFS personally, so I'm not sure exactly what tests to run on it;
> hopefully someone else can take care of that.
> 
>> If you could try that on Xen 4.0 at least (if I remember correctly
>> that's when the vector callback was introduced), you should see the PV
>> timer getting attached, and a performance increase.
> 
> Testing on a cr1.8xlarge EC2 instance, I get Xen 4.2, but it ends up with
> a panic -- console output below.  I can get a backtrace and possibly even
> a dump if those would help.

Hello Colin,

Thanks for the test, I've been using Xen 4.2 (and 4.3) without problems 
so far. By looking at the Xen code, the only reason the timer setup 
could return -22 (EINVAL), is that we try to set the timer for a 
different vCPU than the one we are running on.

I've been able to boot a 32 vCPU DomU on my 8way box using Xen 4.2.1 
(using both qemu-xen and qemu-xen-traditional device models), so I'm 
unsure if this could be due to some patch Amazon applies to Xen. Could 
you try the following patch and post the error message? I would like to 
see if the cpuid reported by kdb and the vCPU that we are trying to set 
the timer are the same.

Booting...
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-CURRENT #68: Wed May 22 19:00:14 CEST 2013
root@:/usr/obj/usr/src/sys/XENHVM amd64
FreeBSD clang version 3.3 (trunk 178860) 20130405
WARNING: WITNESS option enabled, expect reduced performance.
XEN: Hypervisor version 4.2 detected.
CPU: Intel(R) Xeon(R) CPU   W3550  @ 3.07GHz (3066.83-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x106a5  Family = 0x6  Model = 0x1a  Stepping = 
5
  
Features=0x1783fbff
  Features2=0x81b82201
  AMD Features=0x28100800
  AMD Features2=0x1
real memory  = 4286578688 (4088 MB)
avail memory = 3961323520 (3777 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs
FreeBSD/SMP: 2 package(s) x 16 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  2
 cpu2 (AP): APIC ID:  4
 cpu3 (AP): APIC ID:  6
 cpu4 (AP): APIC ID:  8
 cpu5 (AP): APIC ID: 10
 cpu6 (AP): APIC ID: 12
 cpu7 (AP): APIC ID: 14
 cpu8 (AP): APIC ID: 16
 cpu9 (AP): APIC ID: 18
 cpu10 (AP): APIC ID: 20
 cpu11 (AP): APIC ID: 22
 cpu12 (AP): APIC ID: 24
 cpu13 (AP): APIC ID: 26
 cpu14 (AP): APIC ID: 28
 cpu15 (AP): APIC ID: 30
 cpu16 (AP): APIC ID: 32
 cpu17 (AP): APIC ID: 34
 cpu18 (AP): APIC ID: 36
 cpu19 (AP): APIC ID: 38
 cpu20 (AP): APIC ID: 40
 cpu21 (AP): APIC ID: 42
 cpu22 (AP): APIC ID: 44
 cpu23 (AP): APIC ID: 46
 cpu24 (AP): APIC ID: 48
 cpu25 (AP): APIC ID: 50
 cpu26 (AP): APIC ID: 52
 cpu27 (AP): APIC ID: 54
 cpu28 (AP): APIC ID: 56
 cpu29 (AP): APIC ID: 58
 cpu30 (AP): APIC ID: 60
 cpu31 (AP): APIC ID: 62
random device not loaded; using insecure entropy
ioapic0: Changing APIC ID to 1
MADT: Forcing active-low polarity and level trigger for SCI
ioapic0  irqs 0-47 on motherboard
kbd1 at kbdmux0
xen_et0:  on motherboard
Event timer "XENTIMER" frequency 10 Hz quality 950
Timecounter "XENTIMER" frequency 10 Hz quality 950
acpi0:  on motherboard
acpi0: Power Button (fixed)
acpi0: Sleep Button (fixed)
acpi0: reservation of 0, a (3) failed
cpu0:  on acpi0
cpu1:  on acpi0
cpu2:  on acpi0
cpu3:  on acpi0
cpu4:  on acpi0
cpu5:  on acpi0
cpu6:  on acpi0
cpu7:  on acpi0
cpu8:  on acpi0
cpu9:  on acpi0
cpu10:  on acpi0
cpu11:  on acpi0
cpu12:  on acpi0
cpu13:  on acpi0
cpu14:  on acpi0
cpu15:  on acpi0
cpu16:  on acpi0
cpu17:  on acpi0
cpu18:  on acpi0
cpu19:  on acpi0
cpu20:  on acpi0
cpu21:  on acpi0
cpu22:  on acpi0
cpu23:  on acpi0
cpu24:  on acpi0
cpu25:  on acpi0
cpu26:  on acpi0
cpu27:  on acpi0
cpu28:  on acpi0
cpu29:  on acpi0
cpu30:  on acpi0
cpu31:  on acpi0
hpet0:  iomem 0xfed0-0xfed003ff on acpi0
Timecounter "HPET" frequency 6250 Hz quality 950
attimer0:  port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
atrtc0:  port 0x70-0x71 irq 8 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <32-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
isab0:  at device 1.0 on pci0
isa0:  on isab0
atapci0

Re: FreeBSD PVHVM call for testing

[Colin Percival]

On 05/22/13 04:45, Roger Pau Monné wrote:
> On 18/05/13 17:44, Colin Percival wrote:
>> That seems to work.  dmesg is attached.  Are there any particular tests
>> you'd like me to run?
> 
> I have not tested ZFS, that might be a good one. If you are running this
> on Xen 3.4 the behaviour should be the same as without this patches, so
> there shouldn't be many differences.

I don't use ZFS personally, so I'm not sure exactly what tests to run on it;
hopefully someone else can take care of that.

> If you could try that on Xen 4.0 at least (if I remember correctly
> that's when the vector callback was introduced), you should see the PV
> timer getting attached, and a performance increase.

Testing on a cr1.8xlarge EC2 instance, I get Xen 4.2, but it ends up with
a panic -- console output below.  I can get a backtrace and possibly even
a dump if those would help.

Booting [/boot/kernel/kernel]...
-\|/-\|GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
SMAP type=01 base= len=0009e000
SMAP type=02 base=0009e000 len=2000
SMAP type=02 base=000e len=0002
SMAP type=01 base=0010 len=eff0
SMAP type=02 base=fc00 len=0400
SMAP type=01 base=0001 len=003c1900
Table 'FACP' at 0xfc014980
Table 'APIC' at 0xfc014a80
APIC: Found table at 0xfc014a80
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 0: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 2 ACPI ID 1: enabled
SMP: Added CPU 2 (AP)
MADT: Found CPU APIC ID 4 ACPI ID 2: enabled
SMP: Added CPU 4 (AP)
MADT: Found CPU APIC ID 6 ACPI ID 3: enabled
SMP: Added CPU 6 (AP)
MADT: Found CPU APIC ID 8 ACPI ID 4: enabled
SMP: Added CPU 8 (AP)
MADT: Found CPU APIC ID 10 ACPI ID 5: enabled
SMP: Added CPU 10 (AP)
MADT: Found CPU APIC ID 12 ACPI ID 6: enabled
SMP: Added CPU 12 (AP)
MADT: Found CPU APIC ID 14 ACPI ID 7: enabled
SMP: Added CPU 14 (AP)
MADT: Found CPU APIC ID 32 ACPI ID 8: enabled
SMP: Added CPU 32 (AP)
MADT: Found CPU APIC ID 34 ACPI ID 9: enabled
SMP: Added CPU 34 (AP)
MADT: Found CPU APIC ID 36 ACPI ID 10: enabled
SMP: Added CPU 36 (AP)
MADT: Found CPU APIC ID 38 ACPI ID 11: enabled
SMP: Added CPU 38 (AP)
MADT: Found CPU APIC ID 40 ACPI ID 12: enabled
SMP: Added CPU 40 (AP)
MADT: Found CPU APIC ID 42 ACPI ID 13: enabled
SMP: Added CPU 42 (AP)
MADT: Found CPU APIC ID 44 ACPI ID 14: enabled
SMP: Added CPU 44 (AP)
MADT: Found CPU APIC ID 46 ACPI ID 15: enabled
SMP: Added CPU 46 (AP)
MADT: Found CPU APIC ID 1 ACPI ID 16: enabled
SMP: Added CPU 1 (AP)
MADT: Found CPU APIC ID 3 ACPI ID 17: enabled
SMP: Added CPU 3 (AP)
MADT: Found CPU APIC ID 5 ACPI ID 18: enabled
SMP: Added CPU 5 (AP)
MADT: Found CPU APIC ID 7 ACPI ID 19: enabled
SMP: Added CPU 7 (AP)
MADT: Found CPU APIC ID 9 ACPI ID 20: enabled
SMP: Added CPU 9 (AP)
MADT: Found CPU APIC ID 11 ACPI ID 21: enabled
SMP: Added CPU 11 (AP)
MADT: Found CPU APIC ID 13 ACPI ID 22: enabled
SMP: Added CPU 13 (AP)
MADT: Found CPU APIC ID 15 ACPI ID 23: enabled
SMP: Added CPU 15 (AP)
MADT: Found CPU APIC ID 33 ACPI ID 24: enabled
SMP: Added CPU 33 (AP)
MADT: Found CPU APIC ID 35 ACPI ID 25: enabled
SMP: Added CPU 35 (AP)
MADT: Found CPU APIC ID 37 ACPI ID 26: enabled
SMP: Added CPU 37 (AP)
MADT: Found CPU APIC ID 39 ACPI ID 27: enabled
SMP: Added CPU 39 (AP)
MADT: Found CPU APIC ID 41 ACPI ID 28: enabled
SMP: Added CPU 41 (AP)
MADT: Found CPU APIC ID 43 ACPI ID 29: enabled
SMP: Added CPU 43 (AP)
MADT: Found CPU APIC ID 45 ACPI ID 30: enabled
SMP: Added CPU 45 (AP)
MADT: Found CPU APIC ID 47 ACPI ID 31: enabled
SMP: Added CPU 47 (AP)
MADT: Found CPU APIC ID 0 ACPI ID 32: disabled
MADT: Found CPU APIC ID 0 ACPI ID 33: disabled
MADT: Found CPU APIC ID 0 ACPI ID 34: disabled
MADT: Found CPU APIC ID 0 ACPI ID 35: disabled
MADT: Found CPU APIC ID 0 ACPI ID 36: disabled
MADT: Found CPU APIC ID 0 ACPI ID 37: disabled
MADT: Found CPU APIC ID 0 ACPI ID 38: disabled
MADT: Found CPU APIC ID 0 ACPI ID 39: disabled
MADT: Found CPU APIC ID 0 ACPI ID 40: disabled
MADT: Found CPU APIC ID 0 ACPI ID 41: disabled
MADT: Found CPU APIC ID 0 ACPI ID 42: disabled
MADT: Found CPU APIC ID 0 ACPI ID 43: disabled
MADT: Found CPU APIC ID 0 ACPI ID 44: disabled
MADT: Found CPU APIC ID 0 ACPI ID 45: disabled
MADT: Found CPU APIC ID 0 ACPI ID 46: disabled
MADT: Found CPU APIC ID 0 ACPI ID 47: disabled
MADT: Found CPU APIC ID 0 ACPI ID 48: disabled
MADT: Found CPU APIC ID 0 ACPI ID 49: disabled
MADT: Found CPU APIC ID 0 ACPI ID 50: disabled
MADT: Found CPU APIC ID 0 ACPI ID 51: disabled
MADT: Found CPU APIC ID 0 ACPI ID 52: disabled
MADT: Found CPU APIC ID 0 ACPI ID 53: disabled
MADT: Found CPU APIC ID 0 ACPI ID 54: disabled
MADT: Found CPU APIC ID 0 ACPI ID 55: disabled
MADT: Found CPU APIC ID 0 ACPI ID 56: disabled
MADT: Found CPU APIC ID 0 ACPI ID 57: disabled
MADT: Found CPU APIC ID 0 ACPI ID 58: disabled
MADT: Found CPU APIC ID 0 ACPI ID 59: disabled
MADT: Found CPU APIC 

Re: FreeBSD PVHVM call for testing

[Yuriy Kohut]

Hi,

I've just successfully run FreeBSD 9.1 based guest with 'pvhvm_v8' based kernel 
under Xen 3.4.4.

Hypervisor details:
# xm info
host   : ***
release: 2.6.18-348.2.1.el5xen
version: #1 SMP Tue Mar 5 17:05:33 EST 2013
machine: x86_64
nr_cpus: 4
nr_nodes   : 1
cores_per_socket   : 4
threads_per_core   : 1
cpu_mhz: 2128
hw_caps: 
bfebfbff:28100800::0340:009ce3bd::0001:
virt_caps  : hvm
total_memory   : 6135
free_memory: 262
node_to_cpu: node0:0-3
node_to_memory : node0:262
xen_major  : 3
xen_minor  : 4
xen_extra  : .4
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=0x8000
xen_changeset  : unavailable
cc_compiler: gcc version 4.1.2 20080704 (Red Hat 4.1.2-52)
cc_compile_by  : root
cc_compile_domain  : **
cc_compile_date: Wed Sep  5 18:01:10 EEST 2012
xend_config_format : 4


DomU details:
# xm list --long h283bpm53f9rnx
(domain
(domid 61)
(on_crash restart)
(uuid a2cbcba9-1d66-87ce-6d2f-412e70eab051)
(bootloader_args )
(vcpus 2)
(name h283bpm53f9rnx)
(on_poweroff destroy)
(on_reboot restart)
(cpus (() ()))
(bootloader )
(maxmem 1024)
(memory 1024)
(shadow_memory 10)
(features )
(on_xend_start ignore)
(on_xend_stop ignore)
(start_time 1369235607.92)
(cpu_time 31.914003553)
(online_vcpus 2)
(image
(hvm
(kernel )
(videoram 4)
(hpet 0)
(stdvga 0)
(loader /usr/lib/xen/boot/hvmloader)
(vncunused 1)
(xen_platform_pci 1)
(boot cd)
(rtc_timeoffset 7202)
(pci ())
(pae 1)
(vpt_align 1)
(hap 1)
(viridian 0)
(acpi 1)
(localtime 0)
(timer_mode 1)
(vnc 1)
(nographic 0)
(guest_os_type default)
(pci_msitranslate 1)
(apic 1)
(monitor 0)
(usbdevice tablet)
(device_model /usr/lib64/xen/bin/qemu-dm)
(pci_power_mgmt 0)
(usb 0)
(xauthority /root/.Xauthority)
(isa 0)
(notes (SUSPEND_CANCEL 1))
)
)
(status 2)
(state -b)
(store_mfn 1044476)
(device
(vif
(bridge xnh5getjoj54ke)
(uuid 6133c146-48ea-b7a5-0263-fda98e1a30fe)
(script /etc/xen/scripts/vif-bridge)
(ip 83.170.81.183)
(mac 00:16:3e:a4:02:5a)
(vifname t2vd5w22msrv5d)
(backend 0)
)
)
(device
(vbd
(protocol x86_64-abi)
(uuid dd857cd1-2a4c-ea21-a5a5-e95d811f607a)
(bootable 1)
(dev hda:disk)
(uname phy:/dev/9yblt1m70pdtdp/ddfhogyred6bby)
(mode w)
(backend 0)
(bootable 1)
(VDI )
)
)
(device
(vbd
(protocol x86_64-abi)
(uuid 19cae15c-354d-77cb-57ec-dc313f1d05ba)
(bootable 0)
(dev hdb:disk)
(uname phy:/dev/9yblt1m70pdtdp/dhnnwhs6jh9kdd)
(mode w)
(backend 0)
(bootable 0)
(VDI )
)
)
(device
(vbd
(protocol x86_64-abi)
(uuid 2b97ec8c-0cc5-7197-f510-63c272449680)
(bootable 0)
(dev hdc:disk)
(uname phy:/dev/9yblt1m70pdtdp/d1jilc7s7jxsaq)
(mode w)
(backend 0)
(bootable 0)
(VDI )
)
)
(device
(vbd
(protocol x86_64-abi)
(uuid 1b472270-1ef3-2f49-81f1-031cc00c0eb7)
(bootable 0)
(dev hdd:cdrom)
(uname file:/tools/freebsd/boot-freebsd-generic.iso)
(mode r)
(backend 0)
(bootable 0)
(VDI )
)
)
(device
(vfb
(vncunused 1)
(vnc 1)
(uuid b3defeea-4acc-1408-9b22-71547a64e705)
(location 0.0.0.0:5900)
)
)
(device
(console
(protocol vt100)
(location 4)
(uuid 58a089ce-a4d0-037e-23e8-9df37b2bd5da)
)
)
)


DomU from "inside":
# uname -a
FreeBSD yurak1.vm 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r+03cdadc: Wed May 22 
17:47:40 EEST 2013 r...@yurak1.vm:/usr/obj/data/freebsd/sys/XENHVM  amd64


I'll also set up one (hope will have some time) under Xen 4.2.2 tomorrow.
---
Yura

On May 13, 2013, at 21:32 PM, Roger Pau Monné  wrote:

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

On 18/05/13 17:44, Colin Percival wrote:
> On 05/18/13 02:50, Roger Pau Monné wrote:
>> On 17/05/13 05:07, Colin Percival wrote:
>>> On 05/16/13 17:43, Roger Pau Monné wrote:
 Thanks for testing this on EC2, could you post the full dmesg? So I can
 see the hypervisor version and if the PV timer is loaded or not.
>>>
>>> Here's what I get on a cc2.8xlarge with boot_verbose=YES:
>>
>> I've pushed a new branch to my repository, pvhvm_v7 that should work,
>> there was a bug with PCI event channel interrupt set up. I've tested
>> with 3.4 and seems OK, but of course it doesn't support the vector
>> callback injection.
> 
> That seems to work.  dmesg is attached.  Are there any particular tests
> you'd like me to run?

I have not tested ZFS, that might be a good one. If you are running this
on Xen 3.4 the behaviour should be the same as without this patches, so
there shouldn't be many differences.

If you could try that on Xen 4.0 at least (if I remember correctly
that's when the vector callback was introduced), you should see the PV
timer getting attached, and a performance increase.

> If anyone else wants to play with this, you can launch ami-e75c358e in the
> EC2 us-east-1 region.
> 

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Colin Percival]

On 05/18/13 02:50, Roger Pau Monné wrote:
> On 17/05/13 05:07, Colin Percival wrote:
>> On 05/16/13 17:43, Roger Pau Monné wrote:
>>> Thanks for testing this on EC2, could you post the full dmesg? So I can
>>> see the hypervisor version and if the PV timer is loaded or not.
>>
>> Here's what I get on a cc2.8xlarge with boot_verbose=YES:
> 
> I've pushed a new branch to my repository, pvhvm_v7 that should work,
> there was a bug with PCI event channel interrupt set up. I've tested
> with 3.4 and seems OK, but of course it doesn't support the vector
> callback injection.

That seems to work.  dmesg is attached.  Are there any particular tests
you'd like me to run?

If anyone else wants to play with this, you can launch ami-e75c358e in the
EC2 us-east-1 region.

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
Table 'FACP' at 0xfc005ee0
Table 'APIC' at 0xfc005fe0
APIC: Found table at 0xfc005fe0
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 0: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 2 ACPI ID 1: enabled
SMP: Added CPU 2 (AP)
MADT: Found CPU APIC ID 4 ACPI ID 2: enabled
SMP: Added CPU 4 (AP)
MADT: Found CPU APIC ID 6 ACPI ID 3: enabled
SMP: Added CPU 6 (AP)
MADT: Found CPU APIC ID 8 ACPI ID 4: enabled
SMP: Added CPU 8 (AP)
MADT: Found CPU APIC ID 10 ACPI ID 5: enabled
SMP: Added CPU 10 (AP)
MADT: Found CPU APIC ID 12 ACPI ID 6: enabled
SMP: Added CPU 12 (AP)
MADT: Found CPU APIC ID 14 ACPI ID 7: enabled
SMP: Added CPU 14 (AP)
MADT: Found CPU APIC ID 32 ACPI ID 8: enabled
SMP: Added CPU 32 (AP)
MADT: Found CPU APIC ID 34 ACPI ID 9: enabled
SMP: Added CPU 34 (AP)
MADT: Found CPU APIC ID 36 ACPI ID 10: enabled
SMP: Added CPU 36 (AP)
MADT: Found CPU APIC ID 38 ACPI ID 11: enabled
SMP: Added CPU 38 (AP)
MADT: Found CPU APIC ID 40 ACPI ID 12: enabled
SMP: Added CPU 40 (AP)
MADT: Found CPU APIC ID 42 ACPI ID 13: enabled
SMP: Added CPU 42 (AP)
MADT: Found CPU APIC ID 44 ACPI ID 14: enabled
SMP: Added CPU 44 (AP)
MADT: Found CPU APIC ID 46 ACPI ID 15: enabled
SMP: Added CPU 46 (AP)
MADT: Found CPU APIC ID 1 ACPI ID 16: enabled
SMP: Added CPU 1 (AP)
MADT: Found CPU APIC ID 3 ACPI ID 17: enabled
SMP: Added CPU 3 (AP)
MADT: Found CPU APIC ID 5 ACPI ID 18: enabled
SMP: Added CPU 5 (AP)
MADT: Found CPU APIC ID 7 ACPI ID 19: enabled
SMP: Added CPU 7 (AP)
MADT: Found CPU APIC ID 9 ACPI ID 20: enabled
SMP: Added CPU 9 (AP)
MADT: Found CPU APIC ID 11 ACPI ID 21: enabled
SMP: Added CPU 11 (AP)
MADT: Found CPU APIC ID 13 ACPI ID 22: enabled
SMP: Added CPU 13 (AP)
MADT: Found CPU APIC ID 15 ACPI ID 23: enabled
SMP: Added CPU 15 (AP)
MADT: Found CPU APIC ID 33 ACPI ID 24: enabled
SMP: Added CPU 33 (AP)
MADT: Found CPU APIC ID 35 ACPI ID 25: enabled
SMP: Added CPU 35 (AP)
MADT: Found CPU APIC ID 37 ACPI ID 26: enabled
SMP: Added CPU 37 (AP)
MADT: Found CPU APIC ID 39 ACPI ID 27: enabled
SMP: Added CPU 39 (AP)
MADT: Found CPU APIC ID 41 ACPI ID 28: enabled
SMP: Added CPU 41 (AP)
MADT: Found CPU APIC ID 43 ACPI ID 29: enabled
SMP: Added CPU 43 (AP)
MADT: Found CPU APIC ID 45 ACPI ID 30: enabled
SMP: Added CPU 45 (AP)
MADT: Found CPU APIC ID 47 ACPI ID 31: enabled
SMP: Added CPU 47 (AP)
Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-CURRENT #0 r+9b25356: Sat May 18 14:46:16 UTC 2013
root@ip-10-140-132-115:/usr/obj/usr/src/sys/XENHVM amd64
FreeBSD clang version 3.3 (trunk 178860) 20130405
WARNING: WITNESS option enabled, expect reduced performance.
XEN: Hypervisor version 3.4 detected.
XEN: Disabling emulated block and network devices
Preloaded elf kernel "/boot/kernel/kernel" at 0x81912000.
Hypervisor: Origin = "XenVMMXenVMM"
Calibrating TSC clock ... TSC clock: 2593802768 Hz
CPU: Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz (2593.80-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x206d6  Family = 0x6  Model = 0x2d  Stepping = 
6
  
Features=0x1781fbff
  
Features2=0x9c982201
  AMD Features=0x20100800
  AMD Features2=0x1
real memory  = 65011712000 (62000 MB)
Physical memory chunk(s):
0x1000 - 0x0009bfff, 634880 bytes (155 pages)
0x0010 - 0x001f, 1048576 bytes (256 pages)
0x01972000 - 0xbfff, 3194544128 bytes (779918 pages)
0x0001 - 0x000efeb95fff, 60108136448 bytes (14674838 pages)
avail memory = 60563271680 (57757 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
INTR: Adding local APIC 1 as a target
INTR: Adding local APIC 2 as a target
INTR: Adding local APIC 3 as a target
INTR: Adding local APIC 4 as a target
INTR: Adding local APIC 5 as a target
INTR: Adding local APIC 6 as a target
INTR: Adding local APIC 7 as a target
INTR: Adding local APIC 8 as a target
INTR: Adding local APIC 9 as a ta

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

On 17/05/13 05:07, Colin Percival wrote:
> On 05/16/13 17:43, Roger Pau Monné wrote:
>> Thanks for testing this on EC2, could you post the full dmesg? So I can
>> see the hypervisor version and if the PV timer is loaded or not.
> 
> Here's what I get on a cc2.8xlarge with boot_verbose=YES:

I've pushed a new branch to my repository, pvhvm_v7 that should work,
there was a bug with PCI event channel interrupt set up. I've tested
with 3.4 and seems OK, but of course it doesn't support the vector
callback injection.

Regards, Roger.
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Colin Percival]

On 05/16/13 17:43, Roger Pau Monné wrote:
> Thanks for testing this on EC2, could you post the full dmesg? So I can
> see the hypervisor version and if the PV timer is loaded or not.

Here's what I get on a cc2.8xlarge with boot_verbose=YES:

> Booting [/boot/kernel/kernel]...   
> -\|/-\|GDB: no debug ports present
> KDB: debugger backends: ddb
> KDB: current backend: ddb
> SMAP type=01 base= len=0009fc00
> SMAP type=02 base=0009fc00 len=0400
> SMAP type=02 base=000e len=0002
> SMAP type=01 base=0010 len=bff0
> SMAP type=02 base=fc00 len=0400
> SMAP type=01 base=0001 len=000e6300
> Table 'FACP' at 0xfc005ee0
> Table 'APIC' at 0xfc005fe0
> APIC: Found table at 0xfc005fe0
> APIC: Using the MADT enumerator.
> MADT: Found CPU APIC ID 0 ACPI ID 0: enabled
> SMP: Added CPU 0 (AP)
> MADT: Found CPU APIC ID 2 ACPI ID 1: enabled
> SMP: Added CPU 2 (AP)
> MADT: Found CPU APIC ID 4 ACPI ID 2: enabled
> SMP: Added CPU 4 (AP)
> MADT: Found CPU APIC ID 6 ACPI ID 3: enabled
> SMP: Added CPU 6 (AP)
> MADT: Found CPU APIC ID 8 ACPI ID 4: enabled
> SMP: Added CPU 8 (AP)
> MADT: Found CPU APIC ID 10 ACPI ID 5: enabled
> SMP: Added CPU 10 (AP)
> MADT: Found CPU APIC ID 12 ACPI ID 6: enabled
> SMP: Added CPU 12 (AP)
> MADT: Found CPU APIC ID 14 ACPI ID 7: enabled
> SMP: Added CPU 14 (AP)
> MADT: Found CPU APIC ID 32 ACPI ID 8: enabled
> SMP: Added CPU 32 (AP)
> MADT: Found CPU APIC ID 34 ACPI ID 9: enabled
> SMP: Added CPU 34 (AP)
> MADT: Found CPU APIC ID 36 ACPI ID 10: enabled
> SMP: Added CPU 36 (AP)
> MADT: Found CPU APIC ID 38 ACPI ID 11: enabled
> SMP: Added CPU 38 (AP)
> MADT: Found CPU APIC ID 40 ACPI ID 12: enabled
> SMP: Added CPU 40 (AP)
> MADT: Found CPU APIC ID 42 ACPI ID 13: enabled
> SMP: Added CPU 42 (AP)
> MADT: Found CPU APIC ID 44 ACPI ID 14: enabled
> SMP: Added CPU 44 (AP)
> MADT: Found CPU APIC ID 46 ACPI ID 15: enabled
> SMP: Added CPU 46 (AP)
> MADT: Found CPU APIC ID 1 ACPI ID 16: enabled
> SMP: Added CPU 1 (AP)
> MADT: Found CPU APIC ID 3 ACPI ID 17: enabled
> SMP: Added CPU 3 (AP)
> MADT: Found CPU APIC ID 5 ACPI ID 18: enabled
> SMP: Added CPU 5 (AP)
> MADT: Found CPU APIC ID 7 ACPI ID 19: enabled
> SMP: Added CPU 7 (AP)
> MADT: Found CPU APIC ID 9 ACPI ID 20: enabled
> SMP: Added CPU 9 (AP)
> MADT: Found CPU APIC ID 11 ACPI ID 21: enabled
> SMP: Added CPU 11 (AP)
> MADT: Found CPU APIC ID 13 ACPI ID 22: enabled
> SMP: Added CPU 13 (AP)
> MADT: Found CPU APIC ID 15 ACPI ID 23: enabled
> SMP: Added CPU 15 (AP)
> MADT: Found CPU APIC ID 33 ACPI ID 24: enabled
> SMP: Added CPU 33 (AP)
> MADT: Found CPU APIC ID 35 ACPI ID 25: enabled
> SMP: Added CPU 35 (AP)
> MADT: Found CPU APIC ID 37 ACPI ID 26: enabled
> SMP: Added CPU 37 (AP)
> MADT: Found CPU APIC ID 39 ACPI ID 27: enabled
> SMP: Added CPU 39 (AP)
> MADT: Found CPU APIC ID 41 ACPI ID 28: enabled
> SMP: Added CPU 41 (AP)
> MADT: Found CPU APIC ID 43 ACPI ID 29: enabled
> SMP: Added CPU 43 (AP)
> MADT: Found CPU APIC ID 45 ACPI ID 30: enabled
> SMP: Added CPU 45 (AP)
> MADT: Found CPU APIC ID 47 ACPI ID 31: enabled
> SMP: Added CPU 47 (AP)
> Copyright (c) 1992-2013 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>   The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 10.0-CURRENT #0 r+7c97e5b: Fri May 17 02:38:29 UTC 2013
> root@ip-10-148-212-216:/usr/obj/usr/src/sys/XENHVM amd64
> FreeBSD clang version 3.3 (trunk 178860) 20130405
> WARNING: WITNESS option enabled, expect reduced performance.
> XEN: Hypervisor version 3.4 detected.
> XEN: Disabling emulated block and network devices
> Preloaded elf kernel "/boot/kernel/kernel" at 0x81912000.
> Hypervisor: Origin = "XenVMMXenVMM"
> Calibrating TSC clock ... TSC clock: 2593801200 Hz
> CPU: Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz (2593.80-MHz K8-class CPU)
>   Origin = "GenuineIntel"  Id = 0x206d7  Family = 0x6  Model = 0x2d  Stepping 
> = 7
>   
> Features=0x1781fbff
>   
> Features2=0x9c982201
>   AMD Features=0x20100800
>   AMD Features2=0x1
> real memory  = 65011712000 (62000 MB)
> Physical memory chunk(s):
> 0x1000 - 0x0009bfff, 634880 bytes (155 pages)
> 0x0010 - 0x001f, 1048576 bytes (256 pages)
> 0x01972000 - 0xbfff, 3194544128 bytes (779918 pages)
> 0x0001 - 0x000efeb95fff, 60108136448 bytes (14674838 pages)
> avail memory = 60563271680 (57757 MB)
> Event timer "LAPIC" quality 400
> ACPI APIC Table: 
> INTR: Adding local APIC 1 as a target
> INTR: Adding local APIC 2 as a target
> INTR: Adding local APIC 3 as a target
> INTR: Adding local APIC 4 as a target
> INTR: Adding local APIC 5 as a target
> INTR: Adding local APIC 6 as a target
> INTR: Adding local APIC 7 as a target
> INTR: Adding local APIC 8 as a target
> INT

Re: FreeBSD PVHVM call for testing

[Roger Pau Monné]

On 16/05/13 19:55, Colin Percival wrote:
> On 05/13/13 11:32, Roger Pau Monné wrote:
>> Right now the code is in a state where it can be tested by users, so we
>> would like to encourage FreeBSD and Xen users to test it and provide
>> feedback.
>>
>> The code is available in the following git repository, under the branch
>> pvhvm_v5:
>>
>> http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=summary
>>
>> Also, I've created a wiki page that explains how to set up a FreeBSD
>> PVHVM for testing:
>>
>> http://wiki.xen.org/wiki/Testing_FreeBSD_PVHVM
> 
> I built a XENHVM kernel with this code on EC2, and it hanged after
>> xenbusb_front0:  on xenstore0
> 
> With a XENHVM kernel from FreeBSD HEAD the next line after that is
>> xbd0: 10240MB  at device/vbd/768 on xenbusb_front0
> 
> Any ideas?

Hello Colin,

Thanks for testing this on EC2, could you post the full dmesg? So I can
see the hypervisor version and if the PV timer is loaded or not.

Roger.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Colin Percival]

On 05/13/13 11:32, Roger Pau Monné wrote:
> Right now the code is in a state where it can be tested by users, so we
> would like to encourage FreeBSD and Xen users to test it and provide
> feedback.
> 
> The code is available in the following git repository, under the branch
> pvhvm_v5:
> 
> http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=summary
> 
> Also, I've created a wiki page that explains how to set up a FreeBSD
> PVHVM for testing:
> 
> http://wiki.xen.org/wiki/Testing_FreeBSD_PVHVM

I built a XENHVM kernel with this code on EC2, and it hanged after
> xenbusb_front0:  on xenstore0

With a XENHVM kernel from FreeBSD HEAD the next line after that is
> xbd0: 10240MB  at device/vbd/768 on xenbusb_front0

Any ideas?

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Colin Percival]

On 05/13/13 12:08, Michael Sierchio wrote:
> The Windoze tax is unacceptable for a number of reasons - the primary reason 
> is
> that I'm not running Windows.  I don't think the licensing scheme is unfair 
> for
> those actually running Windows, mind you.

Right, it's definitely annoying having to pay more -- I just wanted to point out
that the ability does exist, if you're willing to pay the price.

> At the AWS Summit, an assertion was made that HVM support might be coming soon
> for all instance types for *NIX OSes.  I hope that's true.

Was it indeed?  I must not have been present for that... it certainly would be
good news.  Certainly all the new instance types they've released in the past
few years have had UNIX HVM support.

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Michael Sierchio]

The Windoze tax is unacceptable for a number of reasons - the primary
reason is that I'm not running Windows.  I don't think the licensing scheme
is unfair for those actually running Windows, mind you.

At the AWS Summit, an assertion was made that HVM support might be coming
soon for all instance types for *NIX OSes.  I hope that's true.

- M


On Mon, May 13, 2013 at 11:59 AM, Colin Percival wrote:

> On 05/13/13 11:52, Michael Sierchio wrote:
> > I think should be encouraged.  We're eagerly awaiting the ability to run
> > FreeBSD in AWS in something other than t1.micro or cluster compute
> > instances.  Should we keep holding out hope, or will AWS make HVM
> available
> > for all instance types before this happens?
>
> Err... my AMIs run on all EC2 instance types.  On some you have to pay the
> Windows rate, that's all.
>
> --
> Colin Percival
> Security Officer Emeritus, FreeBSD | The power to serve
> Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
>
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Colin Percival]

On 05/13/13 11:52, Michael Sierchio wrote:
> I think should be encouraged.  We're eagerly awaiting the ability to run
> FreeBSD in AWS in something other than t1.micro or cluster compute
> instances.  Should we keep holding out hope, or will AWS make HVM available
> for all instance types before this happens?

Err... my AMIs run on all EC2 instance types.  On some you have to pay the
Windows rate, that's all.

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: FreeBSD PVHVM call for testing

[Michael Sierchio]

On Mon, May 13, 2013 at 11:32 AM, Roger Pau Monné 
 wrote:

> Hello,
>
> Recently Justin T Gibbs, Will Andrews and myself have been working on
> improving the Xen support in FreeBSD. The main goal of this was to bring
> full PVHVM support to FreeBSD, right now FreeBSD is only using PV
> interfaces for disk and network interfaces when running as a HVM guest. ...


I think should be encouraged.  We're eagerly awaiting the ability to run
FreeBSD in AWS in something other than t1.micro or cluster compute
instances.  Should we keep holding out hope, or will AWS make HVM available
for all instance types before this happens?

-  M
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"