Adding Xen to the kbuild bot?

Adding Xen to the kbuild bot?

[Andy Lutomirski]

Hi all-

Would it make sense to add some basic Xen PV testing to the kbuild bot?

qemu can boot Xen like this:

qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'

This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.

Linux has never been been able to do virtio under Xen, which will
screw up your scripts, but I'm cautiously optimistic that virtio will
work as expected on a Xen guest starting with Linux 4.6.  If you want
to play around, it should work in this tree:

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=virtio_dma

I'm hoping to get that queued up for real in the next couple of days.

--Andy

Adding Xen to the kbuild bot?

[Andy Lutomirski]

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

Hi all-

Would it make sense to add some basic Xen PV testing to the kbuild bot?

qemu can boot Xen like this:

qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'

This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.

Linux has never been been able to do virtio under Xen, which will
screw up your scripts, but I'm cautiously optimistic that virtio will
work as expected on a Xen guest starting with Linux 4.6.  If you want
to play around, it should work in this tree:

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=virtio_dma

I'm hoping to get that queued up for real in the next couple of days.

--Andy

Re: Adding Xen to the kbuild bot?

[Fengguang Wu]

Hi Andy,

CC more people on Xen testing -- in case OSStest already (or plans to)
cover such test case.

On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
> Hi all-
> 
> Would it make sense to add some basic Xen PV testing to the kbuild bot?

Do you mean to run basic Xen testing on the various kernel trees that
0day robot covers? That is, to catch kernel regressions when running
under Xen.

If the intention is to catch Xen regressions, the OSStest
infrastructure may be a better option:

        git://xenbits.xen.org/osstest.git

> qemu can boot Xen like this:
> 
> qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
> kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
> 
> This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.

Got it. If you have simple working test scripts to illustrate test
details, it'd be a great help for integrating into OSStest or 0day.

> Linux has never been been able to do virtio under Xen, which will
> screw up your scripts, but I'm cautiously optimistic that virtio will
> work as expected on a Xen guest starting with Linux 4.6.  If you want
> to play around, it should work in this tree:
> 
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=virtio_dma
> 
> I'm hoping to get that queued up for real in the next couple of days.

Thanks,
Fengguang

Re: Adding Xen to the kbuild bot?

[Fengguang Wu]

Hi Andy,

CC more people on Xen testing -- in case OSStest already (or plans to)
cover such test case.

On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
> Hi all-
> 
> Would it make sense to add some basic Xen PV testing to the kbuild bot?

Do you mean to run basic Xen testing on the various kernel trees that
0day robot covers? That is, to catch kernel regressions when running
under Xen.

If the intention is to catch Xen regressions, the OSStest
infrastructure may be a better option:

        git://xenbits.xen.org/osstest.git

> qemu can boot Xen like this:
> 
> qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
> kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
> 
> This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.

Got it. If you have simple working test scripts to illustrate test
details, it'd be a great help for integrating into OSStest or 0day.

> Linux has never been been able to do virtio under Xen, which will
> screw up your scripts, but I'm cautiously optimistic that virtio will
> work as expected on a Xen guest starting with Linux 4.6.  If you want
> to play around, it should work in this tree:
> 
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=virtio_dma
> 
> I'm hoping to get that queued up for real in the next couple of days.

Thanks,
Fengguang

Re: Adding Xen to the kbuild bot?

[Fengguang Wu]

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

Hi Andy,

CC more people on Xen testing -- in case OSStest already (or plans to)
cover such test case.

On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
> Hi all-
> 
> Would it make sense to add some basic Xen PV testing to the kbuild bot?

Do you mean to run basic Xen testing on the various kernel trees that
0day robot covers? That is, to catch kernel regressions when running
under Xen.

If the intention is to catch Xen regressions, the OSStest
infrastructure may be a better option:

        git://xenbits.xen.org/osstest.git

> qemu can boot Xen like this:
> 
> qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
> kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
> 
> This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.

Got it. If you have simple working test scripts to illustrate test
details, it'd be a great help for integrating into OSStest or 0day.

> Linux has never been been able to do virtio under Xen, which will
> screw up your scripts, but I'm cautiously optimistic that virtio will
> work as expected on a Xen guest starting with Linux 4.6.  If you want
> to play around, it should work in this tree:
> 
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=virtio_dma
> 
> I'm hoping to get that queued up for real in the next couple of days.

Thanks,
Fengguang

Re: Adding Xen to the kbuild bot?

[Andy Lutomirski]

On Feb 4, 2016 7:11 PM, "Fengguang Wu" <fengguang.wu@intel.com> wrote:
>
> Hi Andy,
>
> CC more people on Xen testing -- in case OSStest already (or plans to)
> cover such test case.
>
> On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
> > Hi all-
> >
> > Would it make sense to add some basic Xen PV testing to the kbuild bot?
>
> Do you mean to run basic Xen testing on the various kernel trees that
> 0day robot covers? That is, to catch kernel regressions when running
> under Xen.
>

Yes, exactly.  I've personally broken Linux as a Xen guest at least twice.

> If the intention is to catch Xen regressions, the OSStest
> infrastructure may be a better option:
>
>         git://xenbits.xen.org/osstest.git

No, I think that 0day should pick one Xen version and stick with it
for a while rather than trying to track the latest version.

>
> > qemu can boot Xen like this:
> >
> > qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
> > kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
> >
> > This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.
>
> Got it. If you have simple working test scripts to illustrate test
> details, it'd be a great help for integrating into OSStest or 0day.

I have a script that will boot to a command prompt, but I don't know
if that's the right way to do it.  I'm not really sure how 0day works
under the hood, but treating Xen as a different configuration or arch
instead of treating it as a different test case might make more sense.

--Andy

Re: Adding Xen to the kbuild bot?

[Andy Lutomirski]

On Feb 4, 2016 7:11 PM, "Fengguang Wu" <fengguang.wu@intel.com> wrote:
>
> Hi Andy,
>
> CC more people on Xen testing -- in case OSStest already (or plans to)
> cover such test case.
>
> On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
> > Hi all-
> >
> > Would it make sense to add some basic Xen PV testing to the kbuild bot?
>
> Do you mean to run basic Xen testing on the various kernel trees that
> 0day robot covers? That is, to catch kernel regressions when running
> under Xen.
>

Yes, exactly.  I've personally broken Linux as a Xen guest at least twice.

> If the intention is to catch Xen regressions, the OSStest
> infrastructure may be a better option:
>
>         git://xenbits.xen.org/osstest.git

No, I think that 0day should pick one Xen version and stick with it
for a while rather than trying to track the latest version.

>
> > qemu can boot Xen like this:
> >
> > qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
> > kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
> >
> > This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.
>
> Got it. If you have simple working test scripts to illustrate test
> details, it'd be a great help for integrating into OSStest or 0day.

I have a script that will boot to a command prompt, but I don't know
if that's the right way to do it.  I'm not really sure how 0day works
under the hood, but treating Xen as a different configuration or arch
instead of treating it as a different test case might make more sense.

--Andy

Re: Adding Xen to the kbuild bot?

[Andy Lutomirski]

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

On Feb 4, 2016 7:11 PM, "Fengguang Wu" <fengguang.wu@intel.com> wrote:
>
> Hi Andy,
>
> CC more people on Xen testing -- in case OSStest already (or plans to)
> cover such test case.
>
> On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
> > Hi all-
> >
> > Would it make sense to add some basic Xen PV testing to the kbuild bot?
>
> Do you mean to run basic Xen testing on the various kernel trees that
> 0day robot covers? That is, to catch kernel regressions when running
> under Xen.
>

Yes, exactly.  I've personally broken Linux as a Xen guest at least twice.

> If the intention is to catch Xen regressions, the OSStest
> infrastructure may be a better option:
>
>         git://xenbits.xen.org/osstest.git

No, I think that 0day should pick one Xen version and stick with it
for a while rather than trying to track the latest version.

>
> > qemu can boot Xen like this:
> >
> > qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
> > kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
> >
> > This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.
>
> Got it. If you have simple working test scripts to illustrate test
> details, it'd be a great help for integrating into OSStest or 0day.

I have a script that will boot to a command prompt, but I don't know
if that's the right way to do it.  I'm not really sure how 0day works
under the hood, but treating Xen as a different configuration or arch
instead of treating it as a different test case might make more sense.

--Andy

Re: Adding Xen to the kbuild bot?

[Fengguang Wu]

On Fri, Feb 05, 2016 at 12:10:56PM -0800, Andy Lutomirski wrote:
> On Feb 4, 2016 7:11 PM, "Fengguang Wu" <fengguang.wu@intel.com> wrote:
> >
> > Hi Andy,
> >
> > CC more people on Xen testing -- in case OSStest already (or plans to)
> > cover such test case.
> >
> > On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
> > > Hi all-
> > >
> > > Would it make sense to add some basic Xen PV testing to the kbuild bot?
> >
> > Do you mean to run basic Xen testing on the various kernel trees that
> > 0day robot covers? That is, to catch kernel regressions when running
> > under Xen.
> >
> 
> Yes, exactly.  I've personally broken Linux as a Xen guest at least twice.
> 
> > If the intention is to catch Xen regressions, the OSStest
> > infrastructure may be a better option:
> >
> >         git://xenbits.xen.org/osstest.git
> 
> No, I think that 0day should pick one Xen version and stick with it
> for a while rather than trying to track the latest version.

OK, got it. So it's suitable to run in 0day.

> > > qemu can boot Xen like this:
> > >
> > > qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
> > > kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
> > >
> > > This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.
> >
> > Got it. If you have simple working test scripts to illustrate test
> > details, it'd be a great help for integrating into OSStest or 0day.
> 
> I have a script that will boot to a command prompt, but I don't know
> if that's the right way to do it.  I'm not really sure how 0day works
> under the hood, but treating Xen as a different configuration or arch
> instead of treating it as a different test case might make more sense.

We can check the script first, then determine the most suitable way to
integrate it into 0day. My guess is, it might be suitable to run as a
new kind of VM host, like this

https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/tree/hosts/vm-kbuild-1G

model: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap
nr_vm: 12
nr_cpu: 2
memory: 1G
disk_type: virtio-scsi
rootfs: debian-x86_64.cgz
hdd_partitions: /dev/sda /dev/sdb /dev/sdc /dev/sdd
swap_partitions: /dev/sde

Thanks,
Fengguang

Re: Adding Xen to the kbuild bot?

[Fengguang Wu]

On Fri, Feb 05, 2016 at 12:10:56PM -0800, Andy Lutomirski wrote:
> On Feb 4, 2016 7:11 PM, "Fengguang Wu" <fengguang.wu@intel.com> wrote:
> >
> > Hi Andy,
> >
> > CC more people on Xen testing -- in case OSStest already (or plans to)
> > cover such test case.
> >
> > On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
> > > Hi all-
> > >
> > > Would it make sense to add some basic Xen PV testing to the kbuild bot?
> >
> > Do you mean to run basic Xen testing on the various kernel trees that
> > 0day robot covers? That is, to catch kernel regressions when running
> > under Xen.
> >
> 
> Yes, exactly.  I've personally broken Linux as a Xen guest at least twice.
> 
> > If the intention is to catch Xen regressions, the OSStest
> > infrastructure may be a better option:
> >
> >         git://xenbits.xen.org/osstest.git
> 
> No, I think that 0day should pick one Xen version and stick with it
> for a while rather than trying to track the latest version.

OK, got it. So it's suitable to run in 0day.

> > > qemu can boot Xen like this:
> > >
> > > qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
> > > kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
> > >
> > > This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.
> >
> > Got it. If you have simple working test scripts to illustrate test
> > details, it'd be a great help for integrating into OSStest or 0day.
> 
> I have a script that will boot to a command prompt, but I don't know
> if that's the right way to do it.  I'm not really sure how 0day works
> under the hood, but treating Xen as a different configuration or arch
> instead of treating it as a different test case might make more sense.

We can check the script first, then determine the most suitable way to
integrate it into 0day. My guess is, it might be suitable to run as a
new kind of VM host, like this

https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/tree/hosts/vm-kbuild-1G

model: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap
nr_vm: 12
nr_cpu: 2
memory: 1G
disk_type: virtio-scsi
rootfs: debian-x86_64.cgz
hdd_partitions: /dev/sda /dev/sdb /dev/sdc /dev/sdd
swap_partitions: /dev/sde

Thanks,
Fengguang

Re: Adding Xen to the kbuild bot?

[Fengguang Wu]

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

On Fri, Feb 05, 2016 at 12:10:56PM -0800, Andy Lutomirski wrote:
> On Feb 4, 2016 7:11 PM, "Fengguang Wu" <fengguang.wu@intel.com> wrote:
> >
> > Hi Andy,
> >
> > CC more people on Xen testing -- in case OSStest already (or plans to)
> > cover such test case.
> >
> > On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
> > > Hi all-
> > >
> > > Would it make sense to add some basic Xen PV testing to the kbuild bot?
> >
> > Do you mean to run basic Xen testing on the various kernel trees that
> > 0day robot covers? That is, to catch kernel regressions when running
> > under Xen.
> >
> 
> Yes, exactly.  I've personally broken Linux as a Xen guest at least twice.
> 
> > If the intention is to catch Xen regressions, the OSStest
> > infrastructure may be a better option:
> >
> >         git://xenbits.xen.org/osstest.git
> 
> No, I think that 0day should pick one Xen version and stick with it
> for a while rather than trying to track the latest version.

OK, got it. So it's suitable to run in 0day.

> > > qemu can boot Xen like this:
> > >
> > > qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
> > > kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
> > >
> > > This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.
> >
> > Got it. If you have simple working test scripts to illustrate test
> > details, it'd be a great help for integrating into OSStest or 0day.
> 
> I have a script that will boot to a command prompt, but I don't know
> if that's the right way to do it.  I'm not really sure how 0day works
> under the hood, but treating Xen as a different configuration or arch
> instead of treating it as a different test case might make more sense.

We can check the script first, then determine the most suitable way to
integrate it into 0day. My guess is, it might be suitable to run as a
new kind of VM host, like this

https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/tree/hosts/vm-kbuild-1G

model: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap
nr_vm: 12
nr_cpu: 2
memory: 1G
disk_type: virtio-scsi
rootfs: debian-x86_64.cgz
hdd_partitions: /dev/sda /dev/sdb /dev/sdc /dev/sdd
swap_partitions: /dev/sde

Thanks,
Fengguang

Re: [Xen-devel] Adding Xen to the kbuild bot?

[Doug Goldstein]

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

On 2/5/16 2:10 PM, Andy Lutomirski wrote:
> On Feb 4, 2016 7:11 PM, "Fengguang Wu" <fengguang.wu@intel.com> wrote:
>>
>> Hi Andy,
>>
>> CC more people on Xen testing -- in case OSStest already (or plans to)
>> cover such test case.
>>
>> On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
>>> Hi all-
>>>
>>> Would it make sense to add some basic Xen PV testing to the kbuild bot?
>>
>> Do you mean to run basic Xen testing on the various kernel trees that
>> 0day robot covers? That is, to catch kernel regressions when running
>> under Xen.
>>
> 
> Yes, exactly.  I've personally broken Linux as a Xen guest at least twice.
> 
>> If the intention is to catch Xen regressions, the OSStest
>> infrastructure may be a better option:
>>
>>         git://xenbits.xen.org/osstest.git
> 
> No, I think that 0day should pick one Xen version and stick with it
> for a while rather than trying to track the latest version.
> 
>>
>>> qemu can boot Xen like this:
>>>
>>> qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
>>> kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
>>>
>>> This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.
>>
>> Got it. If you have simple working test scripts to illustrate test
>> details, it'd be a great help for integrating into OSStest or 0day.
> 
> I have a script that will boot to a command prompt, but I don't know
> if that's the right way to do it.  I'm not really sure how 0day works
> under the hood, but treating Xen as a different configuration or arch
> instead of treating it as a different test case might make more sense.
> 
> --Andy
> 

Andy,

I'd be curious to see the script you use.


Thanks.
-- 
Doug Goldstein


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

Re: Adding Xen to the kbuild bot?

[Doug Goldstein]

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

On 2/5/16 2:10 PM, Andy Lutomirski wrote:
> On Feb 4, 2016 7:11 PM, "Fengguang Wu" <fengguang.wu@intel.com> wrote:
>>
>> Hi Andy,
>>
>> CC more people on Xen testing -- in case OSStest already (or plans to)
>> cover such test case.
>>
>> On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
>>> Hi all-
>>>
>>> Would it make sense to add some basic Xen PV testing to the kbuild bot?
>>
>> Do you mean to run basic Xen testing on the various kernel trees that
>> 0day robot covers? That is, to catch kernel regressions when running
>> under Xen.
>>
> 
> Yes, exactly.  I've personally broken Linux as a Xen guest at least twice.
> 
>> If the intention is to catch Xen regressions, the OSStest
>> infrastructure may be a better option:
>>
>>         git://xenbits.xen.org/osstest.git
> 
> No, I think that 0day should pick one Xen version and stick with it
> for a while rather than trying to track the latest version.
> 
>>
>>> qemu can boot Xen like this:
>>>
>>> qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
>>> kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
>>>
>>> This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.
>>
>> Got it. If you have simple working test scripts to illustrate test
>> details, it'd be a great help for integrating into OSStest or 0day.
> 
> I have a script that will boot to a command prompt, but I don't know
> if that's the right way to do it.  I'm not really sure how 0day works
> under the hood, but treating Xen as a different configuration or arch
> instead of treating it as a different test case might make more sense.
> 
> --Andy
> 

Andy,

I'd be curious to see the script you use.


Thanks.
-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

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

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

Re: [Xen-devel] Adding Xen to the kbuild bot?

[Andy Lutomirski]

On Mon, Feb 8, 2016 at 7:24 AM, Doug Goldstein <cardoe@cardoe.com> wrote:
> On 2/5/16 2:10 PM, Andy Lutomirski wrote:
>> On Feb 4, 2016 7:11 PM, "Fengguang Wu" <fengguang.wu@intel.com> wrote:
>>>
>>> Hi Andy,
>>>
>>> CC more people on Xen testing -- in case OSStest already (or plans to)
>>> cover such test case.
>>>
>>> On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
>>>> Hi all-
>>>>
>>>> Would it make sense to add some basic Xen PV testing to the kbuild bot?
>>>
>>> Do you mean to run basic Xen testing on the various kernel trees that
>>> 0day robot covers? That is, to catch kernel regressions when running
>>> under Xen.
>>>
>>
>> Yes, exactly.  I've personally broken Linux as a Xen guest at least twice.
>>
>>> If the intention is to catch Xen regressions, the OSStest
>>> infrastructure may be a better option:
>>>
>>>         git://xenbits.xen.org/osstest.git
>>
>> No, I think that 0day should pick one Xen version and stick with it
>> for a while rather than trying to track the latest version.
>>
>>>
>>>> qemu can boot Xen like this:
>>>>
>>>> qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
>>>> kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
>>>>
>>>> This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.
>>>
>>> Got it. If you have simple working test scripts to illustrate test
>>> details, it'd be a great help for integrating into OSStest or 0day.
>>
>> I have a script that will boot to a command prompt, but I don't know
>> if that's the right way to do it.  I'm not really sure how 0day works
>> under the hood, but treating Xen as a different configuration or arch
>> instead of treating it as a different test case might make more sense.
>>
>> --Andy
>>
>
> Andy,
>
> I'd be curious to see the script you use.

It's virtme with the --xen option.  You can see what it's doing by
adding --show-command --dry-run.

https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git/

For Xen, I find I need to give it a decent amount of ram.  --qemu-opts
-m 1024 at the end seems to work.

This works out to:

/usr/bin/qemu-system-x86_64 -fsdev
local,id=virtfs1,path=/,security_model=none,readonly -device
virtio-9p-pci,fsdev=virtfs1,mount_tag=/dev/root -machine accel=kvm:tcg
-watchdog i6300esb -cpu host -parallel none -net none -echr 1 -serial
none -chardev stdio,id=console,signal=off,mux=on -serial
chardev:console -mon chardev=console -vga none -display none -kernel
xen-4.5.2 -initrd './arch/x86/boot/bzImage
init=/path/to/virtme/virtme/guest/virtme-init
earlyprintk=serial,,ttyS0,,115200 console=ttyS0 psmouse.proto=exps
"virtme_stty_con=rows 35 cols 179 iutf8" TERM=xterm-256color
rootfstype=9p rootflags=version=9p2000.L,,trans=virtio,,access=any
raid=noautodetect ro' -m 1024

I can simplify this a lot to:

/usr/bin/qemu-system-x86_64 -fsdev
local,id=virtfs1,path=/,security_model=none,readonly -device
virtio-9p-pci,fsdev=virtfs1,mount_tag=/dev/root -machine accel=kvm:tcg
-nographic -kernel xen-4.5.2 -initrd './arch/x86/boot/bzImage
earlyprintk=serial,,ttyS0,,115200 console=ttyS0 rootfstype=9p
rootflags=version=9p2000.L,,trans=virtio,,access=any raid=noautodetect
ro init=/bin/bash' -m 1024

Using virtme's init works a lot better, though, if your goal is to get a shell.

--Andy

Re: Adding Xen to the kbuild bot?

[Andy Lutomirski]

On Mon, Feb 8, 2016 at 7:24 AM, Doug Goldstein <cardoe@cardoe.com> wrote:
> On 2/5/16 2:10 PM, Andy Lutomirski wrote:
>> On Feb 4, 2016 7:11 PM, "Fengguang Wu" <fengguang.wu@intel.com> wrote:
>>>
>>> Hi Andy,
>>>
>>> CC more people on Xen testing -- in case OSStest already (or plans to)
>>> cover such test case.
>>>
>>> On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
>>>> Hi all-
>>>>
>>>> Would it make sense to add some basic Xen PV testing to the kbuild bot?
>>>
>>> Do you mean to run basic Xen testing on the various kernel trees that
>>> 0day robot covers? That is, to catch kernel regressions when running
>>> under Xen.
>>>
>>
>> Yes, exactly.  I've personally broken Linux as a Xen guest at least twice.
>>
>>> If the intention is to catch Xen regressions, the OSStest
>>> infrastructure may be a better option:
>>>
>>>         git://xenbits.xen.org/osstest.git
>>
>> No, I think that 0day should pick one Xen version and stick with it
>> for a while rather than trying to track the latest version.
>>
>>>
>>>> qemu can boot Xen like this:
>>>>
>>>> qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
>>>> kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
>>>>
>>>> This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.
>>>
>>> Got it. If you have simple working test scripts to illustrate test
>>> details, it'd be a great help for integrating into OSStest or 0day.
>>
>> I have a script that will boot to a command prompt, but I don't know
>> if that's the right way to do it.  I'm not really sure how 0day works
>> under the hood, but treating Xen as a different configuration or arch
>> instead of treating it as a different test case might make more sense.
>>
>> --Andy
>>
>
> Andy,
>
> I'd be curious to see the script you use.

It's virtme with the --xen option.  You can see what it's doing by
adding --show-command --dry-run.

https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git/

For Xen, I find I need to give it a decent amount of ram.  --qemu-opts
-m 1024 at the end seems to work.

This works out to:

/usr/bin/qemu-system-x86_64 -fsdev
local,id=virtfs1,path=/,security_model=none,readonly -device
virtio-9p-pci,fsdev=virtfs1,mount_tag=/dev/root -machine accel=kvm:tcg
-watchdog i6300esb -cpu host -parallel none -net none -echr 1 -serial
none -chardev stdio,id=console,signal=off,mux=on -serial
chardev:console -mon chardev=console -vga none -display none -kernel
xen-4.5.2 -initrd './arch/x86/boot/bzImage
init=/path/to/virtme/virtme/guest/virtme-init
earlyprintk=serial,,ttyS0,,115200 console=ttyS0 psmouse.proto=exps
"virtme_stty_con=rows 35 cols 179 iutf8" TERM=xterm-256color
rootfstype=9p rootflags=version=9p2000.L,,trans=virtio,,access=any
raid=noautodetect ro' -m 1024

I can simplify this a lot to:

/usr/bin/qemu-system-x86_64 -fsdev
local,id=virtfs1,path=/,security_model=none,readonly -device
virtio-9p-pci,fsdev=virtfs1,mount_tag=/dev/root -machine accel=kvm:tcg
-nographic -kernel xen-4.5.2 -initrd './arch/x86/boot/bzImage
earlyprintk=serial,,ttyS0,,115200 console=ttyS0 rootfstype=9p
rootflags=version=9p2000.L,,trans=virtio,,access=any raid=noautodetect
ro init=/bin/bash' -m 1024

Using virtme's init works a lot better, though, if your goal is to get a shell.

--Andy

Re: [Xen-devel] Adding Xen to the kbuild bot?

[Andy Lutomirski]

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

On Mon, Feb 8, 2016 at 7:24 AM, Doug Goldstein <cardoe@cardoe.com> wrote:
> On 2/5/16 2:10 PM, Andy Lutomirski wrote:
>> On Feb 4, 2016 7:11 PM, "Fengguang Wu" <fengguang.wu@intel.com> wrote:
>>>
>>> Hi Andy,
>>>
>>> CC more people on Xen testing -- in case OSStest already (or plans to)
>>> cover such test case.
>>>
>>> On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
>>>> Hi all-
>>>>
>>>> Would it make sense to add some basic Xen PV testing to the kbuild bot?
>>>
>>> Do you mean to run basic Xen testing on the various kernel trees that
>>> 0day robot covers? That is, to catch kernel regressions when running
>>> under Xen.
>>>
>>
>> Yes, exactly.  I've personally broken Linux as a Xen guest at least twice.
>>
>>> If the intention is to catch Xen regressions, the OSStest
>>> infrastructure may be a better option:
>>>
>>>         git://xenbits.xen.org/osstest.git
>>
>> No, I think that 0day should pick one Xen version and stick with it
>> for a while rather than trying to track the latest version.
>>
>>>
>>>> qemu can boot Xen like this:
>>>>
>>>> qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
>>>> kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
>>>>
>>>> This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.
>>>
>>> Got it. If you have simple working test scripts to illustrate test
>>> details, it'd be a great help for integrating into OSStest or 0day.
>>
>> I have a script that will boot to a command prompt, but I don't know
>> if that's the right way to do it.  I'm not really sure how 0day works
>> under the hood, but treating Xen as a different configuration or arch
>> instead of treating it as a different test case might make more sense.
>>
>> --Andy
>>
>
> Andy,
>
> I'd be curious to see the script you use.

It's virtme with the --xen option.  You can see what it's doing by
adding --show-command --dry-run.

https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git/

For Xen, I find I need to give it a decent amount of ram.  --qemu-opts
-m 1024 at the end seems to work.

This works out to:

/usr/bin/qemu-system-x86_64 -fsdev
local,id=virtfs1,path=/,security_model=none,readonly -device
virtio-9p-pci,fsdev=virtfs1,mount_tag=/dev/root -machine accel=kvm:tcg
-watchdog i6300esb -cpu host -parallel none -net none -echr 1 -serial
none -chardev stdio,id=console,signal=off,mux=on -serial
chardev:console -mon chardev=console -vga none -display none -kernel
xen-4.5.2 -initrd './arch/x86/boot/bzImage
init=/path/to/virtme/virtme/guest/virtme-init
earlyprintk=serial,,ttyS0,,115200 console=ttyS0 psmouse.proto=exps
"virtme_stty_con=rows 35 cols 179 iutf8" TERM=xterm-256color
rootfstype=9p rootflags=version=9p2000.L,,trans=virtio,,access=any
raid=noautodetect ro' -m 1024

I can simplify this a lot to:

/usr/bin/qemu-system-x86_64 -fsdev
local,id=virtfs1,path=/,security_model=none,readonly -device
virtio-9p-pci,fsdev=virtfs1,mount_tag=/dev/root -machine accel=kvm:tcg
-nographic -kernel xen-4.5.2 -initrd './arch/x86/boot/bzImage
earlyprintk=serial,,ttyS0,,115200 console=ttyS0 rootfstype=9p
rootflags=version=9p2000.L,,trans=virtio,,access=any raid=noautodetect
ro init=/bin/bash' -m 1024

Using virtme's init works a lot better, though, if your goal is to get a shell.

--Andy

Re: Adding Xen to the kbuild bot?

[Andy Lutomirski]

On Fri, Feb 5, 2016 at 5:17 PM, Fengguang Wu <fengguang.wu@intel.com> wrote:
> On Fri, Feb 05, 2016 at 12:10:56PM -0800, Andy Lutomirski wrote:
>> On Feb 4, 2016 7:11 PM, "Fengguang Wu" <fengguang.wu@intel.com> wrote:
>> >
>> > Hi Andy,
>> >
>> > CC more people on Xen testing -- in case OSStest already (or plans to)
>> > cover such test case.
>> >
>> > On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
>> > > Hi all-
>> > >
>> > > Would it make sense to add some basic Xen PV testing to the kbuild bot?
>> >
>> > Do you mean to run basic Xen testing on the various kernel trees that
>> > 0day robot covers? That is, to catch kernel regressions when running
>> > under Xen.
>> >
>>
>> Yes, exactly.  I've personally broken Linux as a Xen guest at least twice.
>>
>> > If the intention is to catch Xen regressions, the OSStest
>> > infrastructure may be a better option:
>> >
>> >         git://xenbits.xen.org/osstest.git
>>
>> No, I think that 0day should pick one Xen version and stick with it
>> for a while rather than trying to track the latest version.
>
> OK, got it. So it's suitable to run in 0day.
>
>> > > qemu can boot Xen like this:
>> > >
>> > > qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
>> > > kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
>> > >
>> > > This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.
>> >
>> > Got it. If you have simple working test scripts to illustrate test
>> > details, it'd be a great help for integrating into OSStest or 0day.
>>
>> I have a script that will boot to a command prompt, but I don't know
>> if that's the right way to do it.  I'm not really sure how 0day works
>> under the hood, but treating Xen as a different configuration or arch
>> instead of treating it as a different test case might make more sense.
>
> We can check the script first, then determine the most suitable way to
> integrate it into 0day. My guess is, it might be suitable to run as a
> new kind of VM host, like this
>
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/tree/hosts/vm-kbuild-1G
>
> model: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap
> nr_vm: 12
> nr_cpu: 2
> memory: 1G
> disk_type: virtio-scsi
> rootfs: debian-x86_64.cgz
> hdd_partitions: /dev/sda /dev/sdb /dev/sdc /dev/sdd
> swap_partitions: /dev/sde

This makes sense to me, but I think it would need an extension to the
configuration language.

The guest virtio code should be in the next -next release.

--Andy

Re: Adding Xen to the kbuild bot?

[Andy Lutomirski]

On Fri, Feb 5, 2016 at 5:17 PM, Fengguang Wu <fengguang.wu@intel.com> wrote:
> On Fri, Feb 05, 2016 at 12:10:56PM -0800, Andy Lutomirski wrote:
>> On Feb 4, 2016 7:11 PM, "Fengguang Wu" <fengguang.wu@intel.com> wrote:
>> >
>> > Hi Andy,
>> >
>> > CC more people on Xen testing -- in case OSStest already (or plans to)
>> > cover such test case.
>> >
>> > On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
>> > > Hi all-
>> > >
>> > > Would it make sense to add some basic Xen PV testing to the kbuild bot?
>> >
>> > Do you mean to run basic Xen testing on the various kernel trees that
>> > 0day robot covers? That is, to catch kernel regressions when running
>> > under Xen.
>> >
>>
>> Yes, exactly.  I've personally broken Linux as a Xen guest at least twice.
>>
>> > If the intention is to catch Xen regressions, the OSStest
>> > infrastructure may be a better option:
>> >
>> >         git://xenbits.xen.org/osstest.git
>>
>> No, I think that 0day should pick one Xen version and stick with it
>> for a while rather than trying to track the latest version.
>
> OK, got it. So it's suitable to run in 0day.
>
>> > > qemu can boot Xen like this:
>> > >
>> > > qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
>> > > kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
>> > >
>> > > This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.
>> >
>> > Got it. If you have simple working test scripts to illustrate test
>> > details, it'd be a great help for integrating into OSStest or 0day.
>>
>> I have a script that will boot to a command prompt, but I don't know
>> if that's the right way to do it.  I'm not really sure how 0day works
>> under the hood, but treating Xen as a different configuration or arch
>> instead of treating it as a different test case might make more sense.
>
> We can check the script first, then determine the most suitable way to
> integrate it into 0day. My guess is, it might be suitable to run as a
> new kind of VM host, like this
>
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/tree/hosts/vm-kbuild-1G
>
> model: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap
> nr_vm: 12
> nr_cpu: 2
> memory: 1G
> disk_type: virtio-scsi
> rootfs: debian-x86_64.cgz
> hdd_partitions: /dev/sda /dev/sdb /dev/sdc /dev/sdd
> swap_partitions: /dev/sde

This makes sense to me, but I think it would need an extension to the
configuration language.

The guest virtio code should be in the next -next release.

--Andy

Re: Adding Xen to the kbuild bot?

[Andy Lutomirski]

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

On Fri, Feb 5, 2016 at 5:17 PM, Fengguang Wu <fengguang.wu@intel.com> wrote:
> On Fri, Feb 05, 2016 at 12:10:56PM -0800, Andy Lutomirski wrote:
>> On Feb 4, 2016 7:11 PM, "Fengguang Wu" <fengguang.wu@intel.com> wrote:
>> >
>> > Hi Andy,
>> >
>> > CC more people on Xen testing -- in case OSStest already (or plans to)
>> > cover such test case.
>> >
>> > On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
>> > > Hi all-
>> > >
>> > > Would it make sense to add some basic Xen PV testing to the kbuild bot?
>> >
>> > Do you mean to run basic Xen testing on the various kernel trees that
>> > 0day robot covers? That is, to catch kernel regressions when running
>> > under Xen.
>> >
>>
>> Yes, exactly.  I've personally broken Linux as a Xen guest at least twice.
>>
>> > If the intention is to catch Xen regressions, the OSStest
>> > infrastructure may be a better option:
>> >
>> >         git://xenbits.xen.org/osstest.git
>>
>> No, I think that 0day should pick one Xen version and stick with it
>> for a while rather than trying to track the latest version.
>
> OK, got it. So it's suitable to run in 0day.
>
>> > > qemu can boot Xen like this:
>> > >
>> > > qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
>> > > kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
>> > >
>> > > This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.
>> >
>> > Got it. If you have simple working test scripts to illustrate test
>> > details, it'd be a great help for integrating into OSStest or 0day.
>>
>> I have a script that will boot to a command prompt, but I don't know
>> if that's the right way to do it.  I'm not really sure how 0day works
>> under the hood, but treating Xen as a different configuration or arch
>> instead of treating it as a different test case might make more sense.
>
> We can check the script first, then determine the most suitable way to
> integrate it into 0day. My guess is, it might be suitable to run as a
> new kind of VM host, like this
>
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/tree/hosts/vm-kbuild-1G
>
> model: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap
> nr_vm: 12
> nr_cpu: 2
> memory: 1G
> disk_type: virtio-scsi
> rootfs: debian-x86_64.cgz
> hdd_partitions: /dev/sda /dev/sdb /dev/sdc /dev/sdd
> swap_partitions: /dev/sde

This makes sense to me, but I think it would need an extension to the
configuration language.

The guest virtio code should be in the next -next release.

--Andy

Re: Adding Xen to the kbuild bot?

[Ian Jackson]

Andy Lutomirski writes ("Re: Adding Xen to the kbuild bot?"):
> On Feb 4, 2016 7:11 PM, "Fengguang Wu" <fengguang.wu@intel.com> wrote:
> > Do you mean to run basic Xen testing on the various kernel trees that
> > 0day robot covers? That is, to catch kernel regressions when running
> > under Xen.

This would be great.

> > If the intention is to catch Xen regressions, the OSStest
> > infrastructure may be a better option:
> >
> >         git://xenbits.xen.org/osstest.git
> 
> No, I think that 0day should pick one Xen version and stick with it
> for a while rather than trying to track the latest version.

I don't have an opinion about whether more kernel testing for Xen
problems should be done with 0day or with wider use of osstest.

In any case, we in the Xen Project have a number of git branches of
Xen which might well suitable for use as a stable input to something
like 0day.

The most obvious would be the osstest output branch for the latest Xen
stable release, which is at
   git://xenbits.xen.org/osstest.git#stable-4.6
(and when 4.7 is released, ...-4.7).  This is subjected to the osstest
push gate so it is known not to be totally broken.

There is also the tested upstream development branch:
   git://xenbits.xen.org/osstest.git#master
which is also the output of an osstest push gate.  The advantage of
using that is that there is no need to explicitly update to a new
Xen release; the disadvantage is that it does change continously.

But both of these have been tested with at least one (usually, older)
version of Linux as dom0 and known to boot a variety of guests.

Ian.

Re: Adding Xen to the kbuild bot?

[Ian Jackson]

Andy Lutomirski writes ("Re: Adding Xen to the kbuild bot?"):
> On Feb 4, 2016 7:11 PM, "Fengguang Wu" <fengguang.wu@intel.com> wrote:
> > Do you mean to run basic Xen testing on the various kernel trees that
> > 0day robot covers? That is, to catch kernel regressions when running
> > under Xen.

This would be great.

> > If the intention is to catch Xen regressions, the OSStest
> > infrastructure may be a better option:
> >
> >         git://xenbits.xen.org/osstest.git
> 
> No, I think that 0day should pick one Xen version and stick with it
> for a while rather than trying to track the latest version.

I don't have an opinion about whether more kernel testing for Xen
problems should be done with 0day or with wider use of osstest.

In any case, we in the Xen Project have a number of git branches of
Xen which might well suitable for use as a stable input to something
like 0day.

The most obvious would be the osstest output branch for the latest Xen
stable release, which is at
   git://xenbits.xen.org/osstest.git#stable-4.6
(and when 4.7 is released, ...-4.7).  This is subjected to the osstest
push gate so it is known not to be totally broken.

There is also the tested upstream development branch:
   git://xenbits.xen.org/osstest.git#master
which is also the output of an osstest push gate.  The advantage of
using that is that there is no need to explicitly update to a new
Xen release; the disadvantage is that it does change continously.

But both of these have been tested with at least one (usually, older)
version of Linux as dom0 and known to boot a variety of guests.

Ian.

Re: Adding Xen to the kbuild bot?

[Andy Lutomirski]

On Wed, Feb 17, 2016 at 12:46 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Fri, Feb 5, 2016 at 5:17 PM, Fengguang Wu <fengguang.wu@intel.com> wrote:
>> On Fri, Feb 05, 2016 at 12:10:56PM -0800, Andy Lutomirski wrote:
>>> On Feb 4, 2016 7:11 PM, "Fengguang Wu" <fengguang.wu@intel.com> wrote:
>>> >
>>> > Hi Andy,
>>> >
>>> > CC more people on Xen testing -- in case OSStest already (or plans to)
>>> > cover such test case.
>>> >
>>> > On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
>>> > > Hi all-
>>> > >
>>> > > Would it make sense to add some basic Xen PV testing to the kbuild bot?
>>> >
>>> > Do you mean to run basic Xen testing on the various kernel trees that
>>> > 0day robot covers? That is, to catch kernel regressions when running
>>> > under Xen.
>>> >
>>>
>>> Yes, exactly.  I've personally broken Linux as a Xen guest at least twice.
>>>
>>> > If the intention is to catch Xen regressions, the OSStest
>>> > infrastructure may be a better option:
>>> >
>>> >         git://xenbits.xen.org/osstest.git
>>>
>>> No, I think that 0day should pick one Xen version and stick with it
>>> for a while rather than trying to track the latest version.
>>
>> OK, got it. So it's suitable to run in 0day.
>>
>>> > > qemu can boot Xen like this:
>>> > >
>>> > > qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
>>> > > kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
>>> > >
>>> > > This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.
>>> >
>>> > Got it. If you have simple working test scripts to illustrate test
>>> > details, it'd be a great help for integrating into OSStest or 0day.
>>>
>>> I have a script that will boot to a command prompt, but I don't know
>>> if that's the right way to do it.  I'm not really sure how 0day works
>>> under the hood, but treating Xen as a different configuration or arch
>>> instead of treating it as a different test case might make more sense.
>>
>> We can check the script first, then determine the most suitable way to
>> integrate it into 0day. My guess is, it might be suitable to run as a
>> new kind of VM host, like this
>>
>> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/tree/hosts/vm-kbuild-1G
>>
>> model: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap
>> nr_vm: 12
>> nr_cpu: 2
>> memory: 1G
>> disk_type: virtio-scsi
>> rootfs: debian-x86_64.cgz
>> hdd_partitions: /dev/sda /dev/sdb /dev/sdc /dev/sdd
>> swap_partitions: /dev/sde
>
> This makes sense to me, but I think it would need an extension to the
> configuration language.
>
> The guest virtio code should be in the next -next release.
>

FWIW, 4.6-rc1 works when booted via Xen on QEMU/KVM with virtio out of the box.

--Andy

Re: Adding Xen to the kbuild bot?

[Andy Lutomirski]

On Wed, Feb 17, 2016 at 12:46 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Fri, Feb 5, 2016 at 5:17 PM, Fengguang Wu <fengguang.wu@intel.com> wrote:
>> On Fri, Feb 05, 2016 at 12:10:56PM -0800, Andy Lutomirski wrote:
>>> On Feb 4, 2016 7:11 PM, "Fengguang Wu" <fengguang.wu@intel.com> wrote:
>>> >
>>> > Hi Andy,
>>> >
>>> > CC more people on Xen testing -- in case OSStest already (or plans to)
>>> > cover such test case.
>>> >
>>> > On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
>>> > > Hi all-
>>> > >
>>> > > Would it make sense to add some basic Xen PV testing to the kbuild bot?
>>> >
>>> > Do you mean to run basic Xen testing on the various kernel trees that
>>> > 0day robot covers? That is, to catch kernel regressions when running
>>> > under Xen.
>>> >
>>>
>>> Yes, exactly.  I've personally broken Linux as a Xen guest at least twice.
>>>
>>> > If the intention is to catch Xen regressions, the OSStest
>>> > infrastructure may be a better option:
>>> >
>>> >         git://xenbits.xen.org/osstest.git
>>>
>>> No, I think that 0day should pick one Xen version and stick with it
>>> for a while rather than trying to track the latest version.
>>
>> OK, got it. So it's suitable to run in 0day.
>>
>>> > > qemu can boot Xen like this:
>>> > >
>>> > > qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
>>> > > kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
>>> > >
>>> > > This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.
>>> >
>>> > Got it. If you have simple working test scripts to illustrate test
>>> > details, it'd be a great help for integrating into OSStest or 0day.
>>>
>>> I have a script that will boot to a command prompt, but I don't know
>>> if that's the right way to do it.  I'm not really sure how 0day works
>>> under the hood, but treating Xen as a different configuration or arch
>>> instead of treating it as a different test case might make more sense.
>>
>> We can check the script first, then determine the most suitable way to
>> integrate it into 0day. My guess is, it might be suitable to run as a
>> new kind of VM host, like this
>>
>> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/tree/hosts/vm-kbuild-1G
>>
>> model: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap
>> nr_vm: 12
>> nr_cpu: 2
>> memory: 1G
>> disk_type: virtio-scsi
>> rootfs: debian-x86_64.cgz
>> hdd_partitions: /dev/sda /dev/sdb /dev/sdc /dev/sdd
>> swap_partitions: /dev/sde
>
> This makes sense to me, but I think it would need an extension to the
> configuration language.
>
> The guest virtio code should be in the next -next release.
>

FWIW, 4.6-rc1 works when booted via Xen on QEMU/KVM with virtio out of the box.

--Andy

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

Re: Adding Xen to the kbuild bot?

[Andy Lutomirski]

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

On Wed, Feb 17, 2016 at 12:46 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Fri, Feb 5, 2016 at 5:17 PM, Fengguang Wu <fengguang.wu@intel.com> wrote:
>> On Fri, Feb 05, 2016 at 12:10:56PM -0800, Andy Lutomirski wrote:
>>> On Feb 4, 2016 7:11 PM, "Fengguang Wu" <fengguang.wu@intel.com> wrote:
>>> >
>>> > Hi Andy,
>>> >
>>> > CC more people on Xen testing -- in case OSStest already (or plans to)
>>> > cover such test case.
>>> >
>>> > On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
>>> > > Hi all-
>>> > >
>>> > > Would it make sense to add some basic Xen PV testing to the kbuild bot?
>>> >
>>> > Do you mean to run basic Xen testing on the various kernel trees that
>>> > 0day robot covers? That is, to catch kernel regressions when running
>>> > under Xen.
>>> >
>>>
>>> Yes, exactly.  I've personally broken Linux as a Xen guest at least twice.
>>>
>>> > If the intention is to catch Xen regressions, the OSStest
>>> > infrastructure may be a better option:
>>> >
>>> >         git://xenbits.xen.org/osstest.git
>>>
>>> No, I think that 0day should pick one Xen version and stick with it
>>> for a while rather than trying to track the latest version.
>>
>> OK, got it. So it's suitable to run in 0day.
>>
>>> > > qemu can boot Xen like this:
>>> > >
>>> > > qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
>>> > > kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
>>> > >
>>> > > This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.
>>> >
>>> > Got it. If you have simple working test scripts to illustrate test
>>> > details, it'd be a great help for integrating into OSStest or 0day.
>>>
>>> I have a script that will boot to a command prompt, but I don't know
>>> if that's the right way to do it.  I'm not really sure how 0day works
>>> under the hood, but treating Xen as a different configuration or arch
>>> instead of treating it as a different test case might make more sense.
>>
>> We can check the script first, then determine the most suitable way to
>> integrate it into 0day. My guess is, it might be suitable to run as a
>> new kind of VM host, like this
>>
>> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/tree/hosts/vm-kbuild-1G
>>
>> model: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap
>> nr_vm: 12
>> nr_cpu: 2
>> memory: 1G
>> disk_type: virtio-scsi
>> rootfs: debian-x86_64.cgz
>> hdd_partitions: /dev/sda /dev/sdb /dev/sdc /dev/sdd
>> swap_partitions: /dev/sde
>
> This makes sense to me, but I think it would need an extension to the
> configuration language.
>
> The guest virtio code should be in the next -next release.
>

FWIW, 4.6-rc1 works when booted via Xen on QEMU/KVM with virtio out of the box.

--Andy

Adding Xen to the kbuild bot?

[Andy Lutomirski]

Hi all-

Would it make sense to add some basic Xen PV testing to the kbuild bot?

qemu can boot Xen like this:

qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'

This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.

Linux has never been been able to do virtio under Xen, which will
screw up your scripts, but I'm cautiously optimistic that virtio will
work as expected on a Xen guest starting with Linux 4.6.  If you want
to play around, it should work in this tree:

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=virtio_dma

I'm hoping to get that queued up for real in the next couple of days.

--Andy