Skip to contentSkip to conversation

runqemu: add user mode (SLIRP) support to x86 QEMU targets

PATCH In review Todor Minchev 3 participants 6 messages Oct 24, 2016 – Oct 25, 2016

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 runqemu: add user mode (SLIRP) support to x86 QEMU targets

Using 'slirp' as a command line option to runqemu will start QEMU with user mode networking instead of creating tun/tap devices. SLIRP does not require root access. By default port 2222 on the host will be mapped to port 22 in the guest. The default port mapping can be overwritten with the QB_SLIRP_OPT variable e.g.

QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::2222-:22"

---
 meta/conf/machine/include/qemuboot-x86.inc | 1 +
 scripts/runqemu                            | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)
meta/conf/machine/include/qemuboot-x86.inc +1 -0
index 06ac983..0870294 100644
@@ -13,3 +13,4 @@ QB_AUDIO_OPT = "-soundhw ac97,es1370"
 QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1"
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
 QB_OPT_APPEND = "-vga vmware -show-cursor -usb -usbdevice tablet -device virtio-rng-pci"
+QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::2222-:22"
scripts/runqemu +2 -1
index dbe17ab..6952f32 100755
@@ -542,7 +542,8 @@ class BaseConfig(object):
     def check_and_set(self):
         """Check configs sanity and set when needed"""
         self.validate_paths()
-        check_tun()
+        if not self.slirp_enabled:
+            check_tun()
         # Check audio
         if self.audio_enabled:
             if not self.get('QB_AUDIO_DRV'):
Signature · 1 line
2.10.1
#1 lore raw
Quoted 7 lines · Todor Minchev

Using 'slirp' as a command line option to runqemu will start QEMU with user mode networking instead of creating tun/tap devices. SLIRP does not require root access. By default port 2222 on the host will be mapped to port 22 in the guest. The default port mapping can be overwritten with the QB_SLIRP_OPT variable e.g.

QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::2222-:22"

In the past patches like this have been rejected for performance and other reasons. While I don't particularly like requiring sudo access for runqemu, adding the 'slirp' option will allow someone w/o root/sudo to be able to run it.

Otherwise, if there is something you can do to make slirp work better (when enabled), that is more likely to be accepted.

--Mark

Quoted 30 lines
---
 meta/conf/machine/include/qemuboot-x86.inc | 1 +
 scripts/runqemu                            | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)
meta/conf/machine/include/qemuboot-x86.inc +1 -0
index 06ac983..0870294 100644
@@ -13,3 +13,4 @@ QB_AUDIO_OPT = "-soundhw ac97,es1370"
 QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1"
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
 QB_OPT_APPEND = "-vga vmware -show-cursor -usb -usbdevice tablet -device virtio-rng-pci"
+QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::2222-:22"
scripts/runqemu +2 -1
index dbe17ab..6952f32 100755
@@ -542,7 +542,8 @@ class BaseConfig(object):
     def check_and_set(self):
         """Check configs sanity and set when needed"""
         self.validate_paths()
-        check_tun()
+        if not self.slirp_enabled:
+            check_tun()
         # Check audio
         if self.audio_enabled:
             if not self.get('QB_AUDIO_DRV'):
#2 lore raw
Quoted 11 lines · Mark Hatle
Quoted 7 lines · Todor Minchev

Using 'slirp' as a command line option to runqemu will start QEMU with user mode networking instead of creating tun/tap devices. SLIRP does not require root access. By default port 2222 on the host will be mapped to port 22 in the guest. The default port mapping can be overwritten with the QB_SLIRP_OPT variable e.g.

QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::2222-:22"

In the past patches like this have been rejected for performance and other reasons.

Performance is not ideal with SLIRP, but should be sufficient for basic ssh access to the guest. Could you please elaborate on the other reasons why having this is a bad idea?

Quoted 2 lines

While I don't particularly like requiring sudo access for runqemu, adding the 'slirp' option will allow someone w/o root/sudo to be able to run it.

The goal was to be able to run a QEMU image and provide basic networking without requiring root access. Is there any reason why running runqemu w/o root/sudo access should be discouraged?

Quoted 2 lines

Otherwise, if there is something you can do to make slirp work better (when enabled), that is more likely to be accepted.

Similar SLIRP support has been already accepted for qemuarm64 with commit 9b0a94cb

--Todor

Intel Open Source Technology Center

Quoted 33 lines

--Mark

Quoted 30 lines
---
 meta/conf/machine/include/qemuboot-x86.inc | 1 +
 scripts/runqemu                            | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)
meta/conf/machine/include/qemuboot-x86.inc +1 -0
index 06ac983..0870294 100644
@@ -13,3 +13,4 @@ QB_AUDIO_OPT = "-soundhw ac97,es1370"
 QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1"
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
 QB_OPT_APPEND = "-vga vmware -show-cursor -usb -usbdevice tablet -device virtio-rng-pci"
+QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::2222-:22"
scripts/runqemu +2 -1
index dbe17ab..6952f32 100755
@@ -542,7 +542,8 @@ class BaseConfig(object):
     def check_and_set(self):
         """Check configs sanity and set when needed"""
         self.validate_paths()
-        check_tun()
+        if not self.slirp_enabled:
+            check_tun()
         # Check audio
         if self.audio_enabled:
             if not self.get('QB_AUDIO_DRV'):
#3 lore raw
Quoted 8 lines · Todor Minchev
Quoted 7 lines · Mark Hatle
Quoted 6 lines · Todor Minchev

Using 'slirp' as a command line option to runqemu will start QEMU with user mode networking instead of creating tun/tap devices. SLIRP does not require root access. By default port 2222 on the host will be mapped to port 22 in the guest. The default port mapping can be overwritten with the QB_SLIRP_OPT variable e.g.

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::2222-:22"

In the past patches like this have been rejected for performance and other reasons.

Performance is not ideal with SLIRP, but should be sufficient for basic ssh access to the guest. Could you please elaborate on the other reasons why having this is a bad idea?

You'd have to go back in the archives. Performance was the main reason I remember being discussed at the time.

I don't remember the others, and as I said, I'm not a fan of requiring root, but the community decided sudo approach was better as long as there was a way to avoid it.

Changing the default will likely require email to the oe-core list and/or oe-architecture list...

Quoted 6 lines
Quoted 2 lines

While I don't particularly like requiring sudo access for runqemu, adding the 'slirp' option will allow someone w/o root/sudo to be able to run it.

The goal was to be able to run a QEMU image and provide basic networking without requiring root access. Is there any reason why running runqemu w/o root/sudo access should be discouraged?

As long as you can pass in slirp (and it's not the default) then I believe your requirement and the community direction is preserved.

Quoted 5 lines
Quoted 2 lines

Otherwise, if there is something you can do to make slirp work better (when enabled), that is more likely to be accepted.

Similar SLIRP support has been already accepted for qemuarm64 with commit 9b0a94cb

Support for slirp is good, it's defaulting to slirp that has been rejected in the past by the community.

Quoted 39 lines

--Todor

Intel Open Source Technology Center

Quoted 33 lines

--Mark

Quoted 30 lines
---
 meta/conf/machine/include/qemuboot-x86.inc | 1 +
 scripts/runqemu                            | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)
meta/conf/machine/include/qemuboot-x86.inc +1 -0
index 06ac983..0870294 100644
@@ -13,3 +13,4 @@ QB_AUDIO_OPT = "-soundhw ac97,es1370"
 QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1"
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
 QB_OPT_APPEND = "-vga vmware -show-cursor -usb -usbdevice tablet -device virtio-rng-pci"
+QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::2222-:22"
scripts/runqemu +2 -1
index dbe17ab..6952f32 100755
@@ -542,7 +542,8 @@ class BaseConfig(object):
     def check_and_set(self):
         """Check configs sanity and set when needed"""
         self.validate_paths()
-        check_tun()
+        if not self.slirp_enabled:
+            check_tun()
         # Check audio
         if self.audio_enabled:
             if not self.get('QB_AUDIO_DRV'):
#4 lore raw

Hi,

This doesn't default to slirp, it just allows it as an option.

In particular, on CROPS containers on Windows 10 and Mac OSX the hypervisor is *not* a linux kernel. This means that the only way we can run qemu in the container for testing/debugging is to run it in slirp mode .since there is no tun/tap device or driver.

So, given that we
1) are not defaulting to slirp and are merely enabling it
2) need slirp mode to be able to run in a CROPS container setting

I think this makes sense.

-Brian
an intel employee

Quoted 104 lines · Mark Hatle
Quoted 11 lines · Todor Minchev
Quoted 10 lines · Mark Hatle
Quoted 7 lines · Todor Minchev

Using 'slirp' as a command line option to runqemu will start QEMU with user mode networking instead of creating tun/tap devices. SLIRP does not require root access. By default port 2222 on the host will be mapped to port 22 in the guest. The default port mapping can be overwritten with the QB_SLIRP_OPT variable e.g.

QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::2222-:22"

In the past patches like this have been rejected for performance and

other

Quoted 5 lines
Quoted 1 line

reasons.

Performance is not ideal with SLIRP, but should be sufficient for basic ssh access to the guest. Could you please elaborate on the other reasons why having this is a bad idea?

You'd have to go back in the archives. Performance was the main reason I remember being discussed at the time.

I don't remember the others, and as I said, I'm not a fan of requiring root, but
the community decided sudo approach was better as long as there was a way to
avoid it.

Changing the default will likely require email to the oe-core list and/or oe-architecture list...

Quoted 2 lines
Quoted 2 lines

While I don't particularly like requiring sudo access for runqemu, adding the 'slirp' option will allow someone w/o root/sudo to be able

to run it.

Quoted 4 lines

The goal was to be able to run a QEMU image and provide basic networking without requiring root access. Is there any reason why running runqemu w/o root/sudo access should be discouraged?

As long as you can pass in slirp (and it's not the default) then I believe your
requirement and the community direction is preserved.

Quoted 1 line
Quoted 1 line

Otherwise, if there is something you can do to make slirp work better

(when

Quoted 4 lines
Quoted 1 line

enabled), that is more likely to be accepted.

Similar SLIRP support has been already accepted for qemuarm64 with commit 9b0a94cb

Support for slirp is good, it's defaulting to slirp that has been rejected in
the past by the community.

Quoted 6 lines

--Todor

Intel Open Source Technology Center

Quoted 2 lines

--Mark

Quoted 7 lines
Quoted 7 lines

Review

Quoted 7 lines
---
 meta/conf/machine/include/qemuboot-x86.inc | 1 +
 scripts/runqemu                            | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)
(quoted diff) +0 -0

b/meta/conf/machine/include/qemuboot-x86.inc

Quoted 5 lines
Quoted 5 lines

meta/conf/machine/include/qemuboot-x86.inc QB_AUDIO_OPT = "-soundhw ac97,es1370" · line 13

Quoted 5 lines

index 06ac983..0870294 100644

meta/conf/machine/include/qemuboot-x86.inc +0 -0
@@ -13,3 +13,4 @@ QB_AUDIO_OPT = "-soundhw ac97,es1370"
 QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=640x480-32

oprofile.timer=1 uvesafb.task_timeout=-1"

Quoted 1 line
Quoted 1 line

meta/conf/machine/include/qemuboot-x86.inc QB_AUDIO_OPT = "-soundhw ac97,es1370" · line 14

Quoted 1 line
meta/conf/machine/include/qemuboot-x86.inc +0 -0
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of

entropy

Quoted 1 line
Quoted 1 line

meta/conf/machine/include/qemuboot-x86.inc QB_AUDIO_OPT = "-soundhw ac97,es1370" · line 15

Quoted 1 line
meta/conf/machine/include/qemuboot-x86.inc +0 -0
 QB_OPT_APPEND = "-vga vmware -show-cursor -usb -usbdevice tablet

-device virtio-rng-pci"

Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
meta/conf/machine/include/qemuboot-x86.inc +1 -0
+QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::2222-:22"
scripts/runqemu +0 -0
index dbe17ab..6952f32 100755
@@ -542,7 +542,8 @@ class BaseConfig(object):
     def check_and_set(self):
         """Check configs sanity and set when needed"""
         self.validate_paths()
Quoted 10 lines
Quoted 8 lines

scripts/runqemu class BaseConfig(object): · line 549

Quoted 7 lines
scripts/runqemu +2 -1
-        check_tun()
+        if not self.slirp_enabled:
+            check_tun()
         # Check audio
         if self.audio_enabled:
             if not self.get('QB_AUDIO_DRV'):

--
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto

#5 lore raw
Quoted 3 lines · Brian Avery

Hi,

This doesn't default to slirp, it just allows it as an option.

Ok.. I misunderstood what it was trying to do then. That sounds fine.

Quoted 10 lines

In particular, on CROPS containers on Windows 10 and Mac OSX the hypervisor is *not* a linux kernel. This means that the only way we can run qemu in the container for testing/debugging is to run it in slirp mode .since there is no tun/tap device or driver.

So, given that we
1) are not defaulting to slirp and are merely enabling it
2) need slirp mode to be able to run in a CROPS container setting

I think this makes sense.

Agreed.

Quoted 107 lines

-Brian
an intel employee

On Mon, Oct 24, 2016 at 5:16 PM, Mark Hatle <[email protected] <mailto:[email protected]>> wrote:

On 10/24/16 6:46 PM, Todor Minchev wrote:
> On Mon, 2016-10-24 at 18:15 -0500, Mark Hatle wrote:
>> On 10/24/16 5:19 PM, Todor Minchev wrote:
>>> Using 'slirp' as a command line option to runqemu will start QEMU >>> with user mode networking instead of creating tun/tap devices. >>> SLIRP does not require root access. By default port 2222 on the >>> host will be mapped to port 22 in the guest. The default port >>> mapping can be overwritten with the QB_SLIRP_OPT variable e.g. >>>
>>> QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::2222-:22" >>
>> In the past patches like this have been rejected for performance and other >> reasons.
>
> Performance is not ideal with SLIRP, but should be sufficient for basic > ssh access to the guest. Could you please elaborate on the other reasons > why having this is a bad idea?

You'd have to go back in the archives. Performance was the main reason I remember being discussed at the time.

I don't remember the others, and as I said, I'm not a fan of requiring root, but the community decided sudo approach was better as long as there was a way to avoid it.

Changing the default will likely require email to the oe-core list and/or oe-architecture list...

>> While I don't particularly like requiring sudo access for runqemu, >> adding the 'slirp' option will allow someone w/o root/sudo to be able to run it. >
> The goal was to be able to run a QEMU image and provide basic networking > without requiring root access. Is there any reason why running runqemu > w/o root/sudo access should be discouraged?

As long as you can pass in slirp (and it's not the default) then I believe your requirement and the community direction is preserved.

>> Otherwise, if there is something you can do to make slirp work better (when >> enabled), that is more likely to be accepted.
>
> Similar SLIRP support has been already accepted for qemuarm64 with > commit 9b0a94cb

Support for slirp is good, it's defaulting to slirp that has been rejected in the past by the community.

> --Todor
>
> Intel Open Source Technology Center
>
>> --Mark
>>
>>> Signed-off-by: Todor Minchev <[email protected] <mailto:[email protected]>>
>>> ---
>>> meta/conf/machine/include/qemuboot-x86.inc | 1 +
>>> scripts/runqemu | 3 ++-
>>> 2 files changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/meta/conf/machine/include/qemuboot-x86.inc b/meta/conf/machine/include/qemuboot-x86.inc
>>> index 06ac983..0870294 100644
>>> --- a/meta/conf/machine/include/qemuboot-x86.inc
>>> +++ b/meta/conf/machine/include/qemuboot-x86.inc
>>> @@ -13,3 +13,4 @@ QB_AUDIO_OPT = "-soundhw ac97,es1370" >>> QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1"
>>> # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
>>> QB_OPT_APPEND = "-vga vmware -show-cursor -usb -usbdevice tablet -device virtio-rng-pci"
>>> +QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::2222-:22" >>> diff --git a/scripts/runqemu b/scripts/runqemu
>>> index dbe17ab..6952f32 100755
>>> --- a/scripts/runqemu
>>> +++ b/scripts/runqemu
>>> @@ -542,7 +542,8 @@ class BaseConfig(object):
>>> def check_and_set(self):
>>> """Check configs sanity and set when needed"""
>>> self.validate_paths()
>>> - check_tun()
>>> + if not self.slirp_enabled:
>>> + check_tun()
>>> # Check audio
>>> if self.audio_enabled:
>>> if not self.get('QB_AUDIO_DRV'):
>>>
>>
>
>

--
_______________________________________________
yocto mailing list
[email protected] <mailto:[email protected]>
https://lists.yoctoproject.org/listinfo/yocto
<https://lists.yoctoproject.org/listinfo/yocto>