date:20110324

[Qemu-devel] target-unicore32: New ISA support for QEMU

2011-03-24 Thread Guan Xuetao

Hi,
I want to add new ISA (UniCore32) support for QEMU.
I have finished unicore32-linux-user development based on qemu-stable-0.14, 
 and will begin unicore32-softmmu work.

What need I do for merging it into QEMU?

Thanks  Regards.

Guan Xuetao
2011/3/24

Re: [Qemu-devel] target-unicore32: New ISA support for QEMU

2011-03-24 Thread Roy Tam

Hi,

2011/3/24 Guan Xuetao g...@mprc.pku.edu.cn:
 Hi,
 I want to add new ISA (UniCore32) support for QEMU.
 I have finished unicore32-linux-user development based on qemu-stable-0.14,
  and will begin unicore32-softmmu work.

 What need I do for merging it into QEMU?


Post the patch sets. Just like what you did in linux-kernel maillist.

 Thanks  Regards.

 Guan Xuetao
 2011/3/24

RE: [Qemu-devel] target-unicore32: New ISA support for QEMU

2011-03-24 Thread Guan Xuetao

 -Original Message-
 From: Roy Tam [mailto:roy...@gmail.com]
 Sent: Thursday, March 24, 2011 2:40 PM
 To: Guan Xuetao
 Cc: qemu-devel@nongnu.org
 Subject: Re: [Qemu-devel] target-unicore32: New ISA support for QEMU

 Hi,

 2011/3/24 Guan Xuetao g...@mprc.pku.edu.cn:
  Hi,
  I want to add new ISA (UniCore32) support for QEMU.
  I have finished unicore32-linux-user development based on qemu-stable-0.14,
   and will begin unicore32-softmmu work.

  What need I do for merging it into QEMU?

 Post the patch sets. Just like what you did in linux-kernel maillist.
Thanks.

Then, I will split the patch set into 3 part:
Patch 1 for target-unicore32 directory
Patch 2 for linux-user/unicore32 directory
Patch 3 for the rest modifications

All patches had  passed checkpatch.pl script.

Guan Xuetao

[Qemu-devel] [Bug 739088] Re: I/O errors after Save/Restore

2011-03-24 Thread Yongjie Ren

this bug is fixed in the latest qemu-kvm.git:
2c9bb5d4e5ae3b12ad71bd6a0c1b32003661f53a

** Changed in: qemu
   Status: New = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/739088

Title:
  I/O errors after Save/Restore

Status in QEMU:
  Fix Released

Bug description:
  qemu-kvm commit: b73357ecd2b14c057134cb71d29447b5b988c516
  ( Author: Marcelo Tosatti mtosa...@redhat.comDate:   Wed Mar 16 
17:04:16 2011 -0300)
  kvm commit: a72e315c509376bbd1e121219c3ad9f23973923f

  After restoring from saved img, some I/O errors appear in dmesg and
  file system is read-only.  I'm sure that the  guest runs normally
  before saving. See the pictures attached in detail.

  Reproduce steps:
  
  1.create a guest:
qemu-img create -b /share/xvs/img/app/ia32e_SMP.img -f qcow2 
/root/test0320.img
qemu-system-x86_64  -m 256  -net 
nic,macaddr=00:16:3e:06:8a:08,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup 
-hda /root/test0320.img
  2.save the guest: 
on qemu monitor: migrate exec:dd of=/root/test-save.img
  3.quit from qemu: 
q command on qemu monitor
  4.restore from img just saved:
qemu-system-x86_64  -m 256  -net 
nic,macaddr=00:16:3e:06:8a:08,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup 
-incoming=/roo/test-save.img
  5.see dmesg in restored guest, you'll find some I/O errors. And run some
  commands such as ps, touch,reboot and so on. Then some I/O errors 
appear.

[Qemu-devel] [Bug 739092] Re: guest hangs when using network after live migration

2011-03-24 Thread Yongjie Ren

this bug is fixed in the latest qemu-kvm.git:
2c9bb5d4e5ae3b12ad71bd6a0c1b32003661f53a

** Changed in: qemu
   Status: New = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/739092

Title:
  guest hangs when using network after live migration

Status in QEMU:
  Fix Released

Bug description:
  qemu-kvm commit: b73357ecd2b14c057134cb71d29447b5b988c516
  ( Author: Marcelo Tosatti mtosa...@redhat.com Date: Wed Mar 16 17:04:16 
2011 -0300)
  kvm commit: a72e315c509376bbd1e121219c3ad9f23973923f

  Guest hangs when I run command ssh/netstat using network after live
  migration. ssh or netstat hangs even if I press Ctrl+C to interrupt. And
  I cannnot connect the guest using ssh GustIP from the host, though the sshd
  is still running in the guest. 

  Reproduce steps:
  
  1.start a tcp daemon for migration:
qemu-system-x86_64  -m 256 -smp 4  -incoming tcp:localhost: -no-acpi 
-net
  nic,macaddr=00:16:3e:63:d5:90,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup
  -hda /root/lv.img
  2.create a guest:
qemu-system-x86_64  -m 256 -smp 4  -no-acpi -net
  nic,macaddr=00:16:3e:63:d5:90,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup
  -hda /root/lv.img
  3.migration: 
migrate tcp:localhost:
  4.run command in guest:
ssh root@192.168.1.177

Re: [Qemu-devel] [RFC] QCFG: a new mechanism to replace QemuOpts and option handling

2011-03-24 Thread Markus Armbruster

Anthony Liguori anth...@codemonkey.ws writes:

 On 03/22/2011 08:01 AM, Markus Armbruster wrote:
 Type checking macros are feasible (see [*] for an existence proof), but
 things do get hairy, and the resulting error messages can be less than
 clear at times.

 That just gives you a warning.  You can do much better things with
 __builtin_types_compatible_p.

Quote of existence proof != this is the best way to do it :)

 But neither really solves the problem I'm talking about.  I can go
 into it in depth but hopefully we both can agree that trying to build
 introspection macros is pretty difficult if not impossible :-)

Depends on what you need from them.

  However,
 this makes it very difficult to support things like lists of lists or
 anything else that would basically require a non-concrete type.
 Sounds like you want a more expressive type system than C's, and propose
 to get it by building your own DSL.  I'm not sure that's wise.

 It's an IDL.  IDL based RPCs are pretty common with C.  The IDL is
 purely declarative.

Still sounds like you want a more expressive type system than C's, and
propose to build it ourselves.

First step would be to define the type system rigorously.

 If you plan to expose these types in a library, you need to either
 explicitly pad each structure and make sure that the padding is
 updated correctly each time a new member is added.
 As long as the data description is data, writing a program to check that
 a new version is compatible with the old one shouldn't be hard.

 If you define the structs on your own, you need to either have a data
 description of the padding or be very careful doing it yourself.

With a program to check compatibility, you can easily make the build
fail when you break compatibility.

  Alternatively, you
 can add an allocation function that automatically pads each structure
 transparently.
 Weaker than a comprehensive check, but could be good enough.

 qmp-gen.py creates qmp-types.[ch] to do exactly the above and also
 generates the type declaration so that you don't have to duplicate the
 type marshalling code and the type declaration.  Today, this is close
 to 2k LOCs so it's actually a significant amount of code code.

 There is also the code that takes the input (via QCFG or QMP) and
 calls an appropriate C function with a strongly typed argument.  I've
 Not sure I got you here.  Perhaps an example could enlighten me :)

 void qapi_free_vnc_info(VncInfo *obj)
 {
 if (!obj) {
 return;
 }
 if (obj-has_host) {
 qemu_free(obj-host);
 }
 if (obj-has_family) {
 qemu_free(obj-family);
 }
 if (obj-has_service) {
 qemu_free(obj-service);
 }
 if (obj-has_auth) {
 qemu_free(obj-auth);
 }
 if (obj-has_clients) {
 qapi_free_vnc_client_info(obj-clients);
 }


 qapi_free_vnc_info(obj-next);
 qemu_free(obj);
 }

 It's pretty basic boiler plate code that could be written by hand, but
 why not generate it.  It actually all adds up pretty quickly in terms
 of SLOCs.

Since we have the data description anyway, why not

for all members
if member needs destruction
destroy it

Just because we can generate boiler-plate code doesn't mean we should
have boiler-plate code.

 The mechanism I described using the visitor pattern is really the
 right solution for vmstate.  The hard problems to solve for vmstate
 are:

 1) How to we support old versions in a robust way.  There are fancy
 things we could do once we have a proper visitor mechanism.  We could
 have special marshallers for old versions, we could treat the output
 of the visitor as an in memory tree and do XSLT style translations,
 etc.

 2) How do we generate the visitor for each device.  I don't think it's
 practical to describe devices in JSON.  It certainly simplifies the
 problem but it seems ugly to me.  I think we realistically need a C
 style IDL and adopt a style of treating it as a header.
 Now I'm confused.  Do you mean your JSON-based DSL won't cut it for
 vmstate?

 If yes, why is it wise to go down that route now?

 There are a few paths we could go.  We can describe devices in JSON.
 This makes VMState introspectable with all of the nice properties of
 everything else.  But the question is, do we describe the full device
 state and then use a separate mechanism to cull out the bits that can
 be recomputed.

 To we only describe the guest visible state and treat that as a
 separate structure?  Is that embedded in the main state object or do
 we explicitly translate the main state object to this new type?

Requiring fields of the externally visible vmstate wire format to be
backed by members of the device state struct (whether they are right in
the outermost struct or not) creates a potentially troublesome tight
coupling between wire format and internal

[Qemu-devel] Re: [0/27] Implement emulation of pSeries logical partitions (v4)

2011-03-24 Thread Alexander Graf


On 24.03.2011, at 05:41, David Gibson wrote:

 On Wed, Mar 23, 2011 at 10:29:04PM +0100, Alexander Graf wrote:
 
 On 23.03.2011, at 22:08, Benjamin Herrenschmidt wrote:
 
 On Wed, 2011-03-23 at 15:45 +0100, Alexander Graf wrote:
 
 What's the magic to start a guest? I tried passing a disk which SLOF
 didn't detect (obviously - there's no IDE there). I also tried running
 a kernel directly with -kernel which gave me no output. How are you
 usually running your images? 
 
 hrm... you using -M pseries right ?
 
 Yup
 
 so -kernel should work with a kernel that is compiled for the pseries
 platform (and it won't use SLOF).
 
 Yeah, that part works.
 
 
 a disk should work with SLOF if you use the default which is scsi (ie
 pseries machine sets that flag that tells qemu to default to scsi, which
 is then picked up by our vscsi).
 
 IE. You should be able to stick a distro ISO in the virtual CD-ROM and
 boot from that with SLOF. SLOF will read the qemu boot list (tho it only
 knows about c, d and n at that stage) and try them in order.
 
 That one doesn't. If I just pass in a disk w/o specifically saying
 it's a scsi disk I end up with no hard disk in the guest :).
 
 Um.. what exact command line are you using?  For me, both -hda file
 and a bare file on the command line work...

Ah, yes. It's the amount of RAM. I didn't pass in -m before which made SLOF not 
detect the SCSI adapter but crash before that.
So yes, please add a min_ram field.


Alex

Re: [Qemu-devel] [PATCH v7] rtl8139: add vlan support

2011-03-24 Thread Jason Wang

On 03/23/2011 07:11 AM, Benjamin Poirier wrote:

Hello,

Here is version 7 of my patchset to add vlan support to the emulated rtl8139
nic.

Changes since v6:
* added check against guest requesting tagging on frames with len 12
* simplified tag extraction in receive function. dot1q_buf arg removed
from rtl8139_do_receive(). Frame is linearized in transfer_frame()
when loopback mode is on.
* added an entry to file header

I've ran the same tests as usual on linux and this time also freebsd 8.2, with
and without vlanhwtso in the latter case. Jason, you're right that loopback
mode is seldom used! It seems the bsd driver only uses it at probe time to
identify a defect in some 8169 [1,2] and even then, that check has been
disabled [3]. The linux driver doesn't support loopback mode (unless it's well
hidden.)

[1]
http://lists.freebsd.org/pipermail/freebsd-emulation/2006-May/thread.html#2055
[2]
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c?rev=1.196;content-type=text%2Fplain
[3] http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c#rev1.68

Changes since v5:
* moved all receive changes to add vlan tag extraction
* fixed checkpatch.pl style issues
* fixed bugs in receive case related to small buffers and loopback
mode. Moved too small buffer code back where it used to be, though
it is changed in content.

Changes since v4:
* removed alloca(), for real. Thanks to the reviewers for their
patience. This patchset now has more versions than the vlan header
has bytes!
* corrected the unlikely, debug printf and long lines, as per comments
* cleaned out ifdef's pertaining to ethernet checksum calculation.
According to a comment since removed they were related to an
optimization:
RTL8139 provides frame CRC with received packet, this feature
seems to be ignored by most drivers, disabled by default
see commit ccf1d14

I've tested v5 using x86_64 host/guest with the usual procedure. I've also ran
the clang analyzer on the qemu code base, just for fun.

Changes since v3:
* removed alloca() and #includenet/ethernet.h as per comments
* reordered patches to put extraction before insertion. Extraction
touches only the receive path but insertion touches both. The two
patches are now needed to have vlan functionnality.

I've tested v4 with x86_64 host/guest. I used the same testing procedure as
before. I've tested a plain configuration as well as one with tso + vlan
offload, successfully.

I had to hack around the Linux 8139cp driver to be able to enable tso on vlan
which leads me to wonder, can someone with access to the C+ spec or a real
card confirm that it can do tso and vlan offload at the same time? The patch
I used for the kernel is at https://gist.github.com/851895.

Changes since v2:
insertion:
* moved insertion later in the process, to handle tso
* use qemu_sendv_packet() to insert the tag for us
* added dot1q_buf parameter to rtl8139_do_receive() to avoid some
memcpy() in loopback mode. Note that the code path through that
function is unchanged when dot1q_buf is NULL.

extraction:
* reduced the amount of copying by moving the frame too short logic
after the removal of the vlan tag (as is done in e1000.c for
example). Unfortunately, that logic can no longer be shared betwen
C+ and C mode.

I've posted v2 of these patches back in November
http://article.gmane.org/gmane.comp.emulators.qemu/84252

I've tested v3 on the following combinations of guest and hosts:
host: x86_64, guest: x86_64
host: x86_64, guest: ppc32
host: ppc32, guest: ppc32

Testing on the x86_64 host used '-net tap' and consisted of:
* making an http transfert on the untagged interface.
* ping -s 0-1472 to another host on a vlan.
* making an scp upload to another host on a vlan.

Testing on the ppc32 host used '-net socket' connected to an x86_64 qemu-kvm
running the virtio nic and consisted of:
* establishing an ssh connection between the two using an untagged interface.
* ping -s 0-1472 between the two using a vlan.
* making an scp transfer in both directions using a vlan.

All that was successful. Nevertheless, it doesn't exercise all code paths so
care is in order.

Please note that the lack of vlan support in rtl8139 has taken a few people
aback:
https://bugzilla.redhat.com/show_bug.cgi?id=516587
http://article.gmane.org/gmane.linux.network.general/14266

99 matches

Mail list logo