[Qemu-devel] Two quick requests.

[Qemu-devel] Two quick requests.

[Rob Landley]

1) When you accidentally run qemu as root, could it NOT try to go into a 
full-screen display by default resulting in a corrupted display you can't 
break out of and have to power cycle the machine?

2) After said reboot, when you're sanely running qemu as a normal user but 
using the hda image file you made as root,  if a hard drive image isn't 
writeable, could it warn or something, rather than having the ubuntu install 
mysteriously fail halfway through when it finds itself unable to 
mount /dev/hda1 after it thinks it just partitioned the drive?  (The error 
messages are a bit vague here, because it _thinks_ earlier steps succeeded.)

Thanks.  0.9.0 looks really nice.  Are qops going in next?

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery

Re: [Qemu-devel] Two quick requests.

[Paul Brook]

On Friday 09 February 2007 22:19, Rob Landley wrote:
> 1) When you accidentally run qemu as root, could it NOT try to go into a
> full-screen display by default resulting in a corrupted display you can't
> break out of and have to power cycle the machine?

This is a feature of your SDL libraries. They're probably trying to use 
console framebuffer output. Complain to whoever supplied your SDL libraries.

> 2) After said reboot, when you're sanely running qemu as a normal user but
> using the hda image file you made as root,  if a hard drive image isn't
> writeable, could it warn or something, rather than having the ubuntu
> install mysteriously fail halfway through when it finds itself unable to
> mount /dev/hda1 after it thinks it just partitioned the drive? 

I think this is also a feature. Previous versions would refuse to use readonly 
images at all.

Paul

Re: [Qemu-devel] Two quick requests.

[Rob Landley]

On Friday 09 February 2007 5:27 pm, Paul Brook wrote:
> On Friday 09 February 2007 22:19, Rob Landley wrote:
> > 1) When you accidentally run qemu as root, could it NOT try to go into a
> > full-screen display by default resulting in a corrupted display you can't
> > break out of and have to power cycle the machine?
> 
> This is a feature of your SDL libraries. They're probably trying to use 
> console framebuffer output. Complain to whoever supplied your SDL libraries.

Ubuntu.  And yeah, probably.

> > 2) After said reboot, when you're sanely running qemu as a normal user but
> > using the hda image file you made as root,  if a hard drive image isn't
> > writeable, could it warn or something, rather than having the ubuntu
> > install mysteriously fail halfway through when it finds itself unable to
> > mount /dev/hda1 after it thinks it just partitioned the drive? 
> 
> I think this is also a feature. Previous versions would refuse to use 
readonly 
> images at all.

Could it warn?  (I admit it'll probably get buried in the "ubuntu doesn't 
default to 1024 hz and you're not root" warning, but I spent a day trying to 
figure this one out.   Slow reboots, and I thought it was another side effect 
of the KDE timeouts. :)

Thanks,

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery

Re: [Qemu-devel] Two quick requests.

[Dan Shearer]

On Fri, Feb 09, 2007 at 10:27:08PM +0000, Paul Brook wrote:
> On Friday 09 February 2007 22:19, Rob Landley wrote:
> > 1) When you accidentally run qemu as root, could it NOT try to go into a
> > full-screen display by default resulting in a corrupted display you can't
> > break out of and have to power cycle the machine?
> 
> This is a feature of your SDL libraries. They're probably trying to use 
> console framebuffer output. Complain to whoever supplied your SDL libraries.

True but I think Rob wants to prevent the  "accidentally" bit because
that isn't the only bad thing you can do with QEMU as root by accident.
The user's intention can be (more or less) detected with a parameter
like "-force-run-as-root". Since once of QEMU's main points is to avoid
the need for root access I think that's reasonable.

-- 
Dan Shearer
dan@shearer.org

Re: [Qemu-devel] Two quick requests.

[Paul Brook]

On Friday 09 February 2007 22:33, Dan Shearer wrote:
> On Fri, Feb 09, 2007 at 10:27:08PM +0000, Paul Brook wrote:
> > On Friday 09 February 2007 22:19, Rob Landley wrote:
> > > 1) When you accidentally run qemu as root, could it NOT try to go into
> > > a full-screen display by default resulting in a corrupted display you
> > > can't break out of and have to power cycle the machine?
> >
> > This is a feature of your SDL libraries. They're probably trying to use
> > console framebuffer output. Complain to whoever supplied your SDL
> > libraries.
>
> True but I think Rob wants to prevent the  "accidentally" bit because
> that isn't the only bad thing you can do with QEMU as root by accident.
> The user's intention can be (more or less) detected with a parameter
> like "-force-run-as-root". Since once of QEMU's main points is to avoid
> the need for root access I think that's reasonable.

I've very little sympathy (read: none) for people who "accidentally" break 
things by running them as root.

Paul

Re: [Qemu-devel] Two quick requests.

[Ed Swierk]

On 2/9/07, Paul Brook <paul@codesourcery.com> wrote:
> I've very little sympathy (read: none) for people who "accidentally" break
> things by running them as root.

Sure, but there are plenty of other ways to accidentally mess up the
permissions of a disk image file. A while back I had to strace qemu to
figure out why file modifications were vanishing after rebooting the
VM; the culprit turned out to be an unrelated script that had set the
image file's mode to 444.

--Ed

Re: [Qemu-devel] Two quick requests.

[Paul Brook]

> Sure, but there are plenty of other ways to accidentally mess up the
> permissions of a disk image file. A while back I had to strace qemu to
> figure out why file modifications were vanishing after rebooting the
> VM; the culprit turned out to be an unrelated script that had set the
> image file's mode to 444.

If you really want to do this, do it properly. Make it an error to use a ro 
image if the user [implicitly] requests rw access.

Paul

CAP_NET_ADMIN (was Re: [Qemu-devel] Two quick requests.)

[Kevin F. Quinn]

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

On Fri, 9 Feb 2007 22:48:51 +0000
Paul Brook <paul@codesourcery.com> wrote:

> I've very little sympathy (read: none) for people who "accidentally"
> break things by running them as root.

On a related note, I've been running qemu(-system 0.8.2) as root
recently as a hopefully temporary measure so that it can setup the
network interfaces.  Recent linux kernels require CAP_NET_ADMIN for the
tun network configuration that qemu does (specifically the TUNSETIFF
ioctl), and the only way to get the capability is to start the process
as root.

Other capabilities could be dropped; as indeed could CAP_NET_ADMIN once
the network configuration is done, but that means modifications to qemu
itself to release the capabilities, and would still leave qemu as a
suid-root binary, which it would be nicer to avoid.

Is there any way around this?  I expected to be able to configure
capabilities for executables in the filesystem, but it appears there
are serious problems with that concept so the kernel doesn't support
it.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: CAP_NET_ADMIN (was Re: [Qemu-devel] Two quick requests.)

[Paul Brook]

> Is there any way around this?  I expected to be able to configure
> capabilities for executables in the filesystem, but it appears there
> are serious problems with that concept so the kernel doesn't support
> it.

Use tunctl to create the device.

Paul

Re: [Qemu-devel] Two quick requests.

[Daniel Jacobowitz]

On Fri, Feb 09, 2007 at 11:06:24PM +0000, Paul Brook wrote:
> > Sure, but there are plenty of other ways to accidentally mess up the
> > permissions of a disk image file. A while back I had to strace qemu to
> > figure out why file modifications were vanishing after rebooting the
> > VM; the culprit turned out to be an unrelated script that had set the
> > image file's mode to 444.
> 
> If you really want to do this, do it properly. Make it an error to use a ro 
> image if the user [implicitly] requests rw access.

But if you do this please be sure not to complain about rw COW images
based on readonly ones...

-- 
Daniel Jacobowitz
CodeSourcery

Re: CAP_NET_ADMIN (was Re: [Qemu-devel] Two quick requests.)

[Chris Friedhoff]

Have a look here with links and a description:
http://www.friedhoff.org/fscaps.html
http://www.friedhoff.org/fscaps.html#Qemu

Serges patch is in the mm tree.

Chris


On Sat, 10 Feb 2007 15:11:00 +0000
Paul Brook <paul@codesourcery.com> wrote:

> > Is there any way around this?  I expected to be able to configure
> > capabilities for executables in the filesystem, but it appears there
> > are serious problems with that concept so the kernel doesn't support
> > it.
> 
> Use tunctl to create the device.
> 
> Paul
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


--------------------
Chris Friedhoff
chris@friedhoff.org

Re: [Qemu-devel] Two quick requests.

[Rob Landley]

On Friday 09 February 2007 6:06 pm, Paul Brook wrote:
> > Sure, but there are plenty of other ways to accidentally mess up the
> > permissions of a disk image file. A while back I had to strace qemu to
> > figure out why file modifications were vanishing after rebooting the
> > VM; the culprit turned out to be an unrelated script that had set the
> > image file's mode to 444.
> 
> If you really want to do this, do it properly. Make it an error to use a ro 
> image if the user [implicitly] requests rw access.

If there's no middle ground between "silently misbehave" and "refuse to start 
if anything _might_ be wrong", then why does current qemu warn about the 1024 
hz thing?

Just curious.  Refusing to start would have saved me a day's debugging time, 
just like the warning would have...

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery

Re: [Qemu-devel] Two quick requests.

[Paul Brook]

> > If you really want to do this, do it properly. Make it an error to use a
> > ro image if the user [implicitly] requests rw access.
>
> If there's no middle ground between "silently misbehave" and "refuse to
> start if anything _might_ be wrong", then why does current qemu warn about
> the 1024 hz thing?

Even at 1024Hz qemu still misbehaves, especially on heavily loaded hosts. 
1024Hz is sufficient for most common operating systems most of the time, but 
many will run happily without it. e.g. many linux kernels only need 100 or 
250Hz.

Paul

Re: [Qemu-devel] Two quick requests.

[Jan Marten Simons]

Rob Landley schrieb:
> On Friday 09 February 2007 6:06 pm, Paul Brook wrote:
>   
>>> Sure, but there are plenty of other ways to accidentally mess up the
>>> permissions of a disk image file. A while back I had to strace qemu to
>>> figure out why file modifications were vanishing after rebooting the
>>> VM; the culprit turned out to be an unrelated script that had set the
>>> image file's mode to 444.
>>>       
>> If you really want to do this, do it properly. Make it an error to use a ro 
>> image if the user [implicitly] requests rw access.
>>     
>
> If there's no middle ground between "silently misbehave" and "refuse to start 
> if anything _might_ be wrong", then why does current qemu warn about the 1024 
> hz thing?
>
> Just curious.  Refusing to start would have saved me a day's debugging time, 
> just like the warning would have...
>
> Rob
>   
I think adding a simple (suppressable) warning on startup would be 
sufficient in case of a ro image.

Jan

[Qemu-devel] QEMU and SMP Option on dual core processor

[Danny Chieh-Yao, Cheng]

Hi all,

I am running a Centrino Duo on Windows XP Home SP2.

Here's the problem...

I want to run the option "-smp 2" with QEMU, but when I start it, it 
says it cannot find cpu1. When I look into task manager and the 
affinity, it's running on CPU0, but if I use imagecfg to set QEMU to run 
on CPU1, it STILL give me the same error. Does anyone know of this problem?

Also, I tried to turn off one processor in BIOs, but there's no such 
option either, I'm using ASUS A8JM laptop.

Regards,
Danny