[Qemu-devel] Nokia N770 and/or N800 emulation

[M. Warner Losh]

Is anybody working on N770 and/or N800 emulation for qemu?

Warner

Re: [kvm-devel] [Qemu-devel] Réf. : Re: [PATCH][RFC] Allowing QEMU to direc tly executeadirectory (and storing command li ne options in it)

[Johannes Schindelin]

Hi,

On Sat, 1 Sep 2007, Avi Kivity wrote:

> Johannes Schindelin wrote:
> >   
> > > I think passing only the directory name is better because it can be like
> > > a "black box" : the user don't have to know how it is inside.
> > > 
> > 
> > I consider this a super downside.
> > 
> > "If you think your users are idiots, only idiots will use it [your
> > software]."
> >   
> 
> I don't consider myself an idiot, yet I get annoyed when software forces me
> to learn its implementation details.

Maybe you missed my point.

If the user executes "qemu -c bla/config", she might get interested in 
looking at that file, and find out that it is easy to modify.  That is 
definitely a benefit worth having.

Ciao,
Dscho

Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)

[Jorge Lucángeli Obes]

On 9/1/07, Andreas Färber <[EMAIL PROTECTED]> wrote:
>
> What you are basically doing is taking up the concept of a bundle but
> call it directory, do not give it a mandatory folder name extension
> and limit the usefulness of the configuration file to your personal
> needs.

I think the problem here is that the scope of this change is not
clear. I _really_ wish to keep this simple. I _really_ wish to avoid
having giant command lines and useless shell scripts. I don't mean to
reinvent the concept of a bundle. Using directories like that seemed a
good way of achieving the purpose of _not_ having to deal with command
lines. Now, it seems that a config file switch is a better choice. I
hardly think that being able to store command line options in a plain
text file is just a matter of _my_ personal needs.

> The configuration file format you are proposing is new because you
> are proposing it now while, as one example, Q has previously
> introduced the concept of bundling a Qemu machine on the Mac. And
> the .plist format has existed for bundles even long before that.
>
> Think about it: If you force frontends to use their own configuration
> files inside the bundle because you want to keep yours simple then
> you force frontends to parse two different configuration files.
> Whereas you yourself just said parsing one XML file was already too
> much for you! Standardizing a more advanced configuration file format
> here and now would enable frontends to exchange such bundles,
> retaining their information. By saying you just want a replacement
> for your command line scripts you are ignoring that other people and
> projects may have more advanced needs.

Those people that have more advanced needs can use the frontends. This
is not meant (necessarily) for frontends. It's meant exactly to
replace command line scripts.

> Oh and this has nothing to do with any virtualization libraries,
> virtualization is not what I (or Q) do so that is no solution at all.
> This is all about invoking QEMU.

libvirt can be perfectly used to invoke QEMU. The name might be
ambiguous, but the functionality is not. In fact, using or not using
KVM with QEMU reduces to selecting a checkbox in libvirt. It's just
another frontend.

> So in the end it simply means that you are taking an existing concept
> and apply it half-heartedly and short-sighted: I might be wrong but
> it seems you have a *nix viewpoint, are not used to working with
> bundles and therefore re-inventing them differently. There are in
> fact "real" bundles on many Linux systems, have a look at pcsc-lite,
> e.g. /usr/lib/pcsc/drivers/ifd-ccid.bundle. This driver bundle has
> the default extension of .bundle, obviously not being opened as a
> document by a user, but users do start up virtual machines with QEMU
> so a custom extension is useful and necessary to detect that the
> directory represents in fact a bundle and more specifically a QEMU
> machine bundle.

This is probably true. I never intended to implement the full concept
of a bundle. Again, I was looking for a way to avoid writing gigantic
command lines; a way that would have consensus in the QEMU community.
As I said in my last mail, the config file switch seems more suited to
do this. For what I intended to solve, implementing the whole "bundle"
thing is overkill. I'd rather not move the complexity of the "bundle"
into QEMU, but rather leave it on the frontends. So, let's just have a
simple way of storing command line options in a config file; a way
that does not conflict with existing frontends.

Cheers,
Jorge

Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)

[Andreas Färber]

Am 01.09.2007 um 20:45 schrieb Jorge Lucángeli Obes:


And I don't understand why, when going along with the bundle idea,
you are suddenly creating a new configuration file format of your
own. There is a standard format, XML or text based, which can be
easily parsed with OSX APIs (and thus likely *Step APIs as well) as a
dictionary, allowing structured information to be stored and thus
allowing Qemu backends to store their own settings alongside. See
attached one my bundles' configuration.plist file (XML serialized) -
relevant is only the Arguments entry, everything else is GUI
specific. I'm not saying this format (the structure) were perfect but
the underlying "property list" format (key, value-type) is standard
for such bundles, so instead of re-inventing the wheel please take a
look at how it's being done!


I would like to think that having command line options separated by
spaces or newlines is a new configuration file format, but it's not.



This patch is not meant as a replacement for libvirt or any other
backend. It's just a replacement for shell scripts that serve the only
purpose of storing command line options. It should be a simple
solution for a simple problem. The complex solution for the complex
problem is already there and is called libvirt. I don't want to have
QEMU parse serialized XML just to replace my '-m 512 -soundhw es1370
-net nic,model=rtl8139' command line. I would simply like to store
that command line somewhere.

Anyways, it's obvious that this is a delicate issue for many people
here. I think the most non-disruptive way of doing this is the '-c'
command line option. It doesn't change QEMU default behaviour, it
doesn't add new hyphen-less options. I insist on the fact that this
should be a simple solution for a simple problem.


What you are basically doing is taking up the concept of a bundle but  
call it directory, do not give it a mandatory folder name extension  
and limit the usefulness of the configuration file to your personal  
needs.


The configuration file format you are proposing is new because you  
are proposing it now while, as one example, Q has previously  
introduced the concept of bundling a Qemu machine on the Mac. And  
the .plist format has existed for bundles even long before that.


Think about it: If you force frontends to use their own configuration  
files inside the bundle because you want to keep yours simple then  
you force frontends to parse two different configuration files.  
Whereas you yourself just said parsing one XML file was already too  
much for you! Standardizing a more advanced configuration file format  
here and now would enable frontends to exchange such bundles,  
retaining their information. By saying you just want a replacement  
for your command line scripts you are ignoring that other people and  
projects may have more advanced needs.


Oh and this has nothing to do with any virtualization libraries,  
virtualization is not what I (or Q) do so that is no solution at all.  
This is all about invoking QEMU.


So in the end it simply means that you are taking an existing concept  
and apply it half-heartedly and short-sighted: I might be wrong but  
it seems you have a *nix viewpoint, are not used to working with  
bundles and therefore re-inventing them differently. There are in  
fact "real" bundles on many Linux systems, have a look at pcsc-lite,  
e.g. /usr/lib/pcsc/drivers/ifd-ccid.bundle. This driver bundle has  
the default extension of .bundle, obviously not being opened as a  
document by a user, but users do start up virtual machines with QEMU  
so a custom extension is useful and necessary to detect that the  
directory represents in fact a bundle and more specifically a QEMU  
machine bundle.


Andreas

Re: [Qemu-devel] Re: e1000 emulation

[Dan Aloni]

On Sun, Aug 26, 2007 at 02:25:57PM +0200, Triggered wrote:
> Dan Aloni schreef:
> > Hello,
> > 
> > Is anyone interested in a patch for an unstable, though working e1000
> > emulation for
> > QEMU? It is aimed for this chip-set version:
> > 
> > 0e:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet
> > Controller
> > 
> > I originally created it very recently to provide a virtual NIC that
> > supports Jumbo
> > packets. Unfortunately it appears that the tun driver doesn't implement
> > change_mtu() so it didn't integrate very well with qemu-kvm.
> > 
> I am very interested in a patch for Gbit-capable network card.
> Please post a patch!

Okay, just a few notes:

 * Sorry for sending this rather badly written patch, I have loads of 
   other stuff at the moment. I hope that it serves as a ground for 
   further development, though.
 * It depends on the e1000_hw.h header from a the Linux kernel driver (look 
   in drivers/net/e1000), I haven't included this header in the patch.
 * As far as I've seen, ICMP ping works, but TCP doesn't (I think it 
   is because this emulator implementation doesn't do the off-load of 
   packet checksuming,  as the guest expects)
 * Several up/downs of the interface while it is working seem to cause 
   guest memory corruption. Haven't looked into this yet.

Have fun hacking!

diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index aeee2af..9363e22 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -372,7 +372,7 @@ VL_OBJS+= scsi-disk.o cdrom.o lsi53c895a.o
 VL_OBJS+= usb.o usb-hub.o usb-linux.o usb-hid.o usb-ohci.o usb-msd.o
 
 # PCI network cards
-VL_OBJS+= ne2000.o rtl8139.o pcnet.o
+VL_OBJS+= ne2000.o rtl8139.o pcnet.o e1000.o
 
 # PCI Hypercall
 VL_OBJS+= hypercall.o
diff --git a/qemu/hw/e1000.c b/qemu/hw/e1000.c
new file mode 100644
index 000..7e3c014
--- /dev/null
+++ b/qemu/hw/e1000.c
@@ -0,0 +1,695 @@
+/*
+ * QEMU e1000 emulation
+ * 
+ * Copyright (c) 2007 Dan Aloni
+ * Based on work done by:
+ * Copyright (c) 2004 Antony T Curtis
+ * 
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+ 
+
+#include "vl.h"
+
+#define E1000_DEBUG
+#define E1000_DEBUG_UNK
+//#define E1000_DEBUG_CSR
+//#define E1000_DEBUG_RMD
+//#define E1000_DEBUG_TMD
+//#define E1000_DEBUG_MATCH
+
+#ifdef E1000_DEBUG
+#defineEDBGOUT(fmt, params...) fprintf(stderr, "e1000: " fmt, ##params)
+#else
+#defineEDBGOUT(fmt, params...) do {} while (0)
+#endif
+
+#ifdef E1000_DEBUG_UNK
+#defineEDBGUNKOUT(fmt, params...) EDBGOUT(fmt, ##params)
+#else
+#defineEDBGUNKOUT(fmt, params...) do {} while (0)
+#endif
+
+
+#define E1000_IOPORT_SIZE   0x40
+#define E1000_PNPMMIO_SIZE  0x6
+
+#include "e1000_hw.h"
+
+typedef struct e1000_vmhw_st e1000_vmhw;
+
+struct e1000_eeprom {
+   unsigned short raw[64];
+};
+
+struct e1000_vmhw_st {
+   PCIDevice dev;
+   PCIDevice *pci_dev;
+   VLANClientState *vc;
+   NICInfo *nd;
+   uint32_t mmio_base;
+   uint32_t interrupt_mask;
+   uint32_t eeprom_semaphore;
+   uint32_t mdic;
+
+   uint32_t icr;
+   uint32_t tdlen;
+   uint64_t tdb;
+   uint32_t tdt;
+   uint32_t tdh;
+
+   uint32_t rdlen;
+   uint64_t rdb;
+   uint32_t rdt;
+   uint32_t rdh;
+   uint32_t rctl;
+   uint32_t receive_buf_size;
+
+   uint16_t phy_regs[0x20];
+
+   struct e1000_eeprom eeprom_data;
+   int eeprom_offset_to_read;
+   int mmio_index, rap, isr, lnkst;
+   void *dma_opaque;
+};
+
+static void e1000_ioport_map(PCIDevice *pci_dev, int region_num, 
+ uint32_t addr, uint32_t size, int type)
+{
+   EDBGOUT("e1000_ioport_map addr=0x%04x size=0x%08x\n", addr, size);
+}
+
+static void e1000_mmio_writeb(void *opaque, target_phys_addr_t addr, uint32_t 
val)
+{
+   EDBGOUT("e1000_mmio_writeb addr=%p val=0x%08x\n", (void *)addr, val);
+}
+
+static uint32_t e1000_mmio_read

Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)

[Jorge Lucángeli Obes]

> And I don't understand why, when going along with the bundle idea,
> you are suddenly creating a new configuration file format of your
> own. There is a standard format, XML or text based, which can be
> easily parsed with OSX APIs (and thus likely *Step APIs as well) as a
> dictionary, allowing structured information to be stored and thus
> allowing Qemu backends to store their own settings alongside. See
> attached one my bundles' configuration.plist file (XML serialized) -
> relevant is only the Arguments entry, everything else is GUI
> specific. I'm not saying this format (the structure) were perfect but
> the underlying "property list" format (key, value-type) is standard
> for such bundles, so instead of re-inventing the wheel please take a
> look at how it's being done!

I would like to think that having command line options separated by
spaces or newlines is a new configuration file format, but it's not.
This patch is not meant as a replacement for libvirt or any other
backend. It's just a replacement for shell scripts that serve the only
purpose of storing command line options. It should be a simple
solution for a simple problem. The complex solution for the complex
problem is already there and is called libvirt. I don't want to have
QEMU parse serialized XML just to replace my '-m 512 -soundhw es1370
-net nic,model=rtl8139' command line. I would simply like to store
that command line somewhere.

Anyways, it's obvious that this is a delicate issue for many people
here. I think the most non-disruptive way of doing this is the '-c'
command line option. It doesn't change QEMU default behaviour, it
doesn't add new hyphen-less options. I insist on the fact that this
should be a simple solution for a simple problem.

Cheers,
Jorge

Re: [Qemu-devel] Re: [et-mgmt-tools] Image Corruption Possible with qemu and qemu-kvm

[Chris Wilson]

Hi all,

On Wed, 29 Aug 2007, Alexander Graf wrote:

Paul Jakma wrote:

On Mon, 27 Aug 2007, Anthony Liguori wrote:

I think this is the right level myself.  Advisory locks work okay but 
not all filesystems support them... I think it would do more harm than 
good to have a feature like that was supposed to provide a safe-guard 
but then frequently didn't work.

   ^^

Are you trying to say that any kind of significant portion of QEMU 
users have clustered file-systems?


I think that's unlikely, and it'd be nice if QEMU by default did a 
fcntl() on writeable image files to lock itself from multiple access, 
that'd benefit the vast majority of users.


I'm usually running one "main" qemu instance that has read/write access 
to the disk file and several others for tests that use the -snapshot 
option, so I think it's very important to have an easy means of 
switching this check off.


Would it make sense to take a read lock (preventing concurrent writes) on 
read-only snapshot images, and a write lock on all writable files? That 
should allow one to run as many instances as you want off a single 
snapshot in snapshot mode, but still prevent one from (accidentally) 
running a non-snapshot QEMU on the same image, or from (accidentally) 
running two instances writing to the same COW file.


By removing the need to add the lock-override command line switch to qemu 
in this case, it would reduce the risk of accidental image corruption by 
accidentally overriding the lock.


Cheers, Chris.
--
_ __ _
\  __/ / ,__(_)_  | Chris Wilson < at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |

[Qemu-devel] Current CVS build errors on RH9

[Robert Reif]

It's been a few months since I comipled from source so I
just tried with current CVS and got these errors on RH9:

/home/wine/qemu/linux-user/syscall.c: In function `sys_tgkill':
/home/wine/qemu/linux-user/syscall.c:170: `__NR_tgkill' undeclared 
(first use in this function)
/home/wine/qemu/linux-user/syscall.c:170: (Each undeclared identifier is 
reported only once

/home/wine/qemu/linux-user/syscall.c:170: for each function it appears in.)

in various subdirectories and:

/home/wine/qemu/vl.c:59:24: linux/hpet.h: No such file or directory
/home/wine/qemu/vl.c: In function `hpet_start_timer':
/home/wine/qemu/vl.c:1222: storage size of `info' isn't known
/home/wine/qemu/vl.c:1230: `HPET_IRQFREQ' undeclared (first use in this 
function)

/home/wine/qemu/vl.c:1230: (Each undeclared identifier is reported only once
/home/wine/qemu/vl.c:1230: for each function it appears in.)
/home/wine/qemu/vl.c:1239: `HPET_INFO' undeclared (first use in this 
function)
/home/wine/qemu/vl.c:1244: `HPET_EPI' undeclared (first use in this 
function)
/home/wine/qemu/vl.c:1249: `HPET_IE_ON' undeclared (first use in this 
function)

/home/wine/qemu/vl.c:1222: warning: unused variable `info'

in various other subdirectories.

Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)

[Andreas Färber]

Am 01.09.2007 um 16:26 schrieb Luke -Jr:


On Saturday 01 September 2007, Markus Hitter wrote:

qemu -c MyImage/vm.cfg


In opposite to "qemu -c MyImage" ?

Why do you want the user to do extra typing? There's one config in
one directory, so typing the config file name is just redundant.


Why would there only be one config in one directory?


Because a bundle is a "special" directory, not /home/yourname or / 
etc. Its sole purpose is to have the appropriate content at the  
correct location. It is usually not modified manually by the user but  
by an application knowing the format.


If you want to have configuration files everywhere I see two  
possibilities:


a) Make it dependent on the bundle extension.
"qemu -c Machine.qvm" (bundle) vs. "qemu -c dir/yourConfig" (config)

b) Use different command line switches.
"qemu -bundle Machine.qvm" vs. "qemu -c yourConfig"

Andreas

Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)

[Andreas Färber]

Am 01.09.2007 um 13:02 schrieb Markus Hitter:



Am 31.08.2007 um 20:54 schrieb Anthony Liguori:


It makes little sense to pass a directory when you can pass a config
file and assume that the directory the config file is in is the CWD.


In fact, most people having designed bundle-type document formats  
came to a different conclusion: . Typically, bundles are opaque and appear like a  
single file to the desktop user.



[...] And then do:

qemu -c MyImage/vm.cfg


In opposite to "qemu -c MyImage" ?

Why do you want the user to do extra typing? There's one config in  
one directory, so typing the config file name is just redundant.



To me, Jorge's implementation looks just fine.


I support the idea of having a bundle for the machine and naming only  
that bundle.


However the bundle still needs an extension. Like I already pointed  
out, on Mac OS X Q uses .qvm for its Qemu guest bundles, making it  
"qemu -c MyGuest.qvm". Or alternatively maybe .qemu?


And I don't understand why, when going along with the bundle idea,  
you are suddenly creating a new configuration file format of your  
own. There is a standard format, XML or text based, which can be  
easily parsed with OSX APIs (and thus likely *Step APIs as well) as a  
dictionary, allowing structured information to be stored and thus  
allowing Qemu backends to store their own settings alongside. See  
attached one my bundles' configuration.plist file (XML serialized) -  
relevant is only the Arguments entry, everything else is GUI  
specific. I'm not saying this format (the structure) were perfect but  
the underlying "property list" format (key, value-type) is standard  
for such bundles, so instead of re-inventing the wheel please take a  
look at how it's being done!


With Q already using this technique and QEMU possibly using bundles  
as well, it would seem like a good idea to synchronize the two  
efforts so that in the end we get only one bundle format instead of  
one for each frontend.


Thanks,

Andreas

configuration.plist
Description: Binary data

Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)

[Luke -Jr]

On Saturday 01 September 2007, Markus Hitter wrote:
> > qemu -c MyImage/vm.cfg
>
> In opposite to "qemu -c MyImage" ?
>
> Why do you want the user to do extra typing? There's one config in
> one directory, so typing the config file name is just redundant.

Why would there only be one config in one directory?

Re: [kvm-devel] [Qemu-devel] Réf. : Re: [PATCH][RFC] Allowing QEMU to direc tly executeadirectory (and storing command li ne options in it)

[Avi Kivity]

Johannes Schindelin wrote:
  
I think passing only the directory name is better because it can be like 
a "black box" : the user don't have to know how it is inside.



I consider this a super downside.

"If you think your users are idiots, only idiots will use it [your 
software]."
  


I don't consider myself an idiot, yet I get annoyed when software forces 
me to learn its implementation details.



--
Any sufficiently difficult bug is indistinguishable from a feature.

Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)

[Markus Hitter]

Am 31.08.2007 um 20:54 schrieb Anthony Liguori:


It makes little sense to pass a directory when you can pass a config
file and assume that the directory the config file is in is the CWD.


In fact, most people having designed bundle-type document formats  
came to a different conclusion: . Typically, bundles are opaque and appear like a single  
file to the desktop user.



[...] And then do:

qemu -c MyImage/vm.cfg


In opposite to "qemu -c MyImage" ?

Why do you want the user to do extra typing? There's one config in  
one directory, so typing the config file name is just redundant.



To me, Jorge's implementation looks just fine.



+   "usage: %s [options] [disk_image|folder]\n"

"usage: %s [options] [diskimage | bundle]\n"
  ^^
Go ahead an call the baby by it's name?


m$0.02
Markus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/

Re: [Qemu-devel] Re: Réf. : Re: [kv m-devel] [PATCH][RFC] Allowing QEMU to directly executeadirectory (and storing command line options in it)

[pterjan]

On 9/1/07, Luke -Jr <[EMAIL PROTECTED]> wrote:
> On Friday 31 August 2007, Anthony Liguori wrote:
> > You're overriding what "qemu my_pc" means.  "qemu my_pc" create a QEMU
> > vm with 128m of memory and -hda my_pc with the default network card.
>
> Why should -hda be assumed instead of -c or -c X/config?

Because it has been for years :)