runqemu: add user mode (SLIRP) support to x86 QEMU targets
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
@@ -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
@@ -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
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_OPTvariable 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
Signed-off-by Todor Minchev <[email protected]>--- 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@@ -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@@ -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'):
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_OPTvariable 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
Signed-off-by Todor Minchev <[email protected]>--- 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@@ -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@@ -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'):
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_OPTvariable 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
Signed-off-by Todor Minchev <[email protected]>--- 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@@ -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@@ -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'):
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_OPTvariable 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
9b0a94cbSupport 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
Signed-off-by Todor Minchev <[email protected]>--- meta/conf/machine/include/qemuboot-x86.inc | 1 + scripts/runqemu | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-)(quoted diff) +0
-0b/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-32oprofile.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 ofentropy
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
-0QB_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@@ -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
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 settingI think this makes sense.
Agreed.
Quoted 107 lines
-Brian
an intel employeeOn 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 theQB_SLIRP_OPTvariable 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 > commit9b0a94cbSupport 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):
>>> defcheck_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 notself.get('QB_AUDIO_DRV'):
>>>
>>
>
>--
_______________________________________________
yocto mailing list
[email protected] <mailto:[email protected]>
https://lists.yoctoproject.org/listinfo/yocto
<https://lists.yoctoproject.org/listinfo/yocto>