On Sun, 2016-06-19 at 19:23 +0200, Cédric Le Goater wrote:
> > You can run a 32-bit OS or firmware on ppc64, but it needs to know that
> > it's running on a 64-bit chip and do a few things differently.
>
> yes sure but qemu would still allow rfi under 64bit CPUs, that is what
> I was concerned ab
On Sun, 2016-06-19 at 19:21 +0200, Cédric Le Goater wrote:
> But, I could not boot ./darwinppc-602.cdr with on a 970. That might
> be another issue.
Right, the issue is that the kernel in Darwin 6.0.2 doesn't support the
970 :-)
I think the first MacOS X to support 970 was some special build of
On Mon, 2016-06-20 at 08:15 +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2016-06-19 at 19:21 +0200, Cédric Le Goater wrote:
> > But, I could not boot ./darwinppc-602.cdr with on a 970. That
> > might
> > be another issue.
>
> Right, the issue is that the kernel in D
On Mon, 2016-06-20 at 08:35 +1000, Benjamin Herrenschmidt wrote:
> ,
> Ok so Darwin uses some of the HSPRG etc... that we don't emulate on
> the 970 so I suspect it never worked. I've added them but something
> else breaks, I'll dig, I have the kernel source so
On Mon, 2016-06-20 at 17:08 +1000, Benjamin Herrenschmidt wrote:
>
> That fixed, it dies elsewhere in something related to page faults,
> still digging.
>
Next problem: Darwin kernel assumes DSISR is 0 on a 0x380 exception !
qemu was leaving it to whatever value it had before. Kab
On Mon, 2016-06-20 at 08:10 +0200, Cédric Le Goater wrote:
> That is how I feel also. So, why don't we just remove the op code in the
> instruction sets from the 32bit CPUs instead of leaving it and testing
> for PPC_SEGMENT_64B ? or is there some reasons we want to keep it around ?
Ah no
Ben.
On Mon, 2016-06-20 at 09:47 +0200, Thomas Huth wrote:
> > Linux ppc behaves the same on a 970. So we will need to fix the 'rfi's
> > there also.
>
> Really? Wow, that surprises me. That OpenBIOS code likely never ran on a
> real 970 hardware, so that's not too much surprising that the "rfi"
> sne
On Mon, 2016-06-20 at 08:17 +0200, Cédric Le Goater wrote:
>
> The current patch does not need fixing. I will send the OpenBIOS
> patch
> shortly after I have looked at the FPU exception.
>
> Linux ppc behaves the same on a 970. So we will need to fix the
> 'rfi's there also.
What do you mean
On Mon, 2016-06-20 at 18:02 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2016-06-20 at 17:08 +1000, Benjamin Herrenschmidt wrote:
> >
> > That fixed, it dies elsewhere in something related to page faults,
> > still digging.
> >
> Next problem: Darwin kernel
On Tue, 2016-06-21 at 09:21 +0100, Mark Cave-Ayland wrote:
> A quick check with "info mtree" shows that this area of memory is PCI
> configuration space. There was a patch added to uninorth in order to
> suppress some PCI warnings on Darwin boot found by going over the source
> to the Darwin MacRIS
On Tue, 2016-06-21 at 19:33 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2016-06-21 at 09:21 +0100, Mark Cave-Ayland wrote:
> > A quick check with "info mtree" shows that this area of memory is
> > PCI
> > configuration space. There was a patch added to uninorth in
Add support to the emulated hardware to add vlan tags in packets going
from the guest to the network.
Signed-off-by: Benjamin Poirier
Cc: Igor V. Kovalenko
---
hw/rtl8139.c | 46 +++---
1 files changed, 35 insertions(+), 11 deletions(-)
diff --git a
Add support to the emulated hardware to remove vlan tags in packets
going from the network to the guest.
Signed-off-by: Benjamin Poirier
Cc: Igor V. Kovalenko
--
AFAIK, extraction is optional to get vlans working. The driver
requests rx detagging but should not assume that it was done. Under
On 08/11/10 11:34 AM, Stefan Hajnoczi wrote:
> On Sun, Nov 7, 2010 at 9:25 PM, Benjamin Poirier
> wrote:
>> Add support to the emulated hardware to add vlan tags in packets going
>> from the guest to the network.
>>
>> Signed-off-by: Benjamin Poirier
>>
Add support to the emulated hardware to add vlan tags in packets going
from the guest to the network.
Signed-off-by: Benjamin Poirier
Cc: Igor V. Kovalenko
---
Changes since v1:
* moved the debug print statement inside the if block and reworded
accordingly. (as suggested by Igor)
hw/rtl8139
Add support to the emulated hardware to remove vlan tags in packets
going from the network to the guest.
Signed-off-by: Benjamin Poirier
Cc: Igor V. Kovalenko
---
Changes since v1:
* moved the debug print statement inside the if block and reworded
accordingly. (as suggested by Igor)
AFAIK
On 16/11/10 03:06 PM, Anthony Liguori wrote:
> On 11/08/2010 07:46 PM, Benjamin Poirier wrote:
>> Add support to the emulated hardware to add vlan tags in packets going
>> from the guest to the network.
>>
>> Signed-off-by: Benjamin Poirier
>> Cc: Igor V. Kov
I am reopening the bug for qemu-kvm, because the patch was dropped in
0.12.4+noroms-0ubuntu1.
** Changed in: qemu-kvm (Ubuntu)
Status: Fix Released => New
--
does not pass pressed caps lock to client
https://bugs.launchpad.net/bugs/427612
You received this bug notification because you are
I modified qemu-kvm to show what keys it receives (patch attached). I am
using the German NEO layout and I get one press and one release event.
Here's the output, if I first press 'caps lock' and then '#':
sdl_process_key({type=0x2,which=0x0,state=0x1,keysym={scancode=0x42,sym=0x139,mod=0x0,unicod
I am reopening the bug again, because I am the original bug reporter and
this bug depends on the keyboard layout.
** Summary changed:
- does not pass pressed caps lock to client
+ kvm sends caps lock key up event twice
** Changed in: qemu-kvm (Ubuntu)
Status: Fix Released => New
--
kvm
libsdl1.2 does not send an key up event for the host caps lock key, but
does send the key up event if the physical caps lock key is mapped to
another key (like NEO2 does). qemu-kvm works around this bug by sending
a key up event for every caps lock key event. The attached patch fixes
the bug for me
Am Montag, den 19.04.2010, 18:07 +0200 schrieb Stefan Weil:
> Kevin Wolf schrieb:
> > Am 19.04.2010 03:23, schrieb Jamie Lokier:
> >> Benjamin Drung wrote:
> >>> - /* SDL does not send the key up event, so we generate it */
> >> Wa
You mean "press caps lock" with "capslock turning on" and "release caps
lock" with "capslock turning off"?
** Description changed:
Binary package hint: qemu-kvm
I have set the keyboard layout to German NEO 2 [1] in the host and the
client (both current karmic). The caps lock is used as m
Attached the patch for qemu-kvm 0.13. This patch is tested on natty with
qemu-kvm 0.13.0+noroms-0ubuntu7 and the German and NEO2 keyboard layout.
** Patch added: "caps-lock-key-up-event.patch"
https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/427612/+attachment/1742131/+files/caps-lock-k
** Also affects: libsdl1.2 (Ubuntu Maverick)
Importance: Undecided
Status: New
** Also affects: qemu-kvm (Ubuntu Maverick)
Importance: Undecided
Status: New
** Changed in: libsdl1.2 (Ubuntu Maverick)
Status: New => Invalid
--
kvm sends caps lock key up event twice
htt
Attached a new version of my patch. You find two branches linked to this
bug for maverick and natty. The patch sets SDL_DISABLE_LOCK_KEYS and get
rid of the complete workaround in qemu-kvm. This requires SDL >= 1.2.14.
Stefan Weil wrote:
>The patch might fix part of the problem, but there remain m
On Wed, 2010-11-24 at 11:46 +0100, Hannes Reinecke wrote:
> >> - when a read is aborted due to a mark/EOF/EOD/EOM, the len
> reported to
> >> controller can be 0. LSI controller emulation doesn't know how to
> manage
> >> this. A workaround found is to call the completion routine with
> >> SCSI_REA
On Thu, 2010-11-25 at 09:50 +0100, Gerd Hoffmann wrote:
> On 11/25/10 09:46, Benjamin Herrenschmidt wrote:
>
> > So far tho, it appears that I can (at least with scsi-disk) rely on
> > always been eventually called with SCSI_REASON_DONE so my code (and
> > maybe the usb
On Thu, 2010-11-25 at 10:06 +0100, Hannes Reinecke wrote:
> No, this is exactly as I'm expecting the SCSI layer to work.
> So from the light of this the patch to scsi-generic is valid.
> And it really looks like papering over a bug in the lsi HBA code.
Ok. I have no special case tho for a complete
Attached the uploaded debdiff for maverick.
** Patch added: "qemu-kvm_0.12.5+noroms-0ubuntu7.1.debdiff"
https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/427612/+attachment/1745373/+files/qemu-kvm_0.12.5%2Bnoroms-0ubuntu7.1.debdiff
** Changed in: qemu-kvm (Ubuntu Maverick)
Status
On Fri, 2010-11-26 at 23:06 +0100, Alexander Graf wrote:
> > http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/prep
>
> I simply replaces explicit bswaps with the flag. Testing prep is hard,
> as recent kernels don't run on it. To be honest, unless someone steps
> up to maintain it I might
Am Donnerstag, den 25.11.2010, 21:08 +0100 schrieb Stefan Weil:
> Am 24.11.2010 22:44, schrieb Benjamin Drung:
> > Attached a new version of my patch. You find two branches linked to this
> > bug for maverick and natty. The patch sets SDL_DISABLE_LOCK_KEYS and get
> >
I have installed the package from maverick-proposed and can confirm that
this bug is fixed by that version.
** Description changed:
Binary package hint: qemu-kvm
I have set the keyboard layout to German NEO 2 [1] in the host and the
client (both current karmic). The caps lock is used as
On Sat, 2010-12-11 at 18:06 +0200, Gleb Natapov wrote:
> http://playground.sun.com/pub/p1275/bindings/pci/pci2_1.pdf has table
> on
> page 10 that defines how pci class code should be translated into OF
> name. This is what my patch is using. pci-ata does not look spec
> compliant (or is there more
> > > Ah the problem is that we have not qdevified mac io bus. Since first to
> > > ide disks are automatically attached to mac-io bus device paths for them
> > > are incorrect. Next two ide devices will be attached to CMD646 and qemu
> > > will generate correct device paths for them:
> > >
> > >
> The only working system emulation we have are Macs (G3 beige, G4, G5),
> so we can't just ignore Apple.
> Alex even made me stick to their odd 0x41 rtas-version property. ;)
Hah :-) Nothing ever used RTAS on these... afaik, it didn't even work
properly.
> No, but that may be OpenBIOS' fault.
On Mon, 2010-12-13 at 08:32 +0100, Hannes Reinecke wrote:
> On 12/10/2010 11:14 PM, Paolo Bonzini wrote:
> > On 11/24/2010 05:50 PM, Christoph Hellwig wrote:
> >> Btw, it might make sense to split this series into two.
> >>
> >> Patches 1 to 11 are genuine improvements to the SCSI code, which I'd
>
On Thu, 2010-12-16 at 12:45 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2010-12-13 at 08:32 +0100, Hannes Reinecke wrote:
> > On 12/10/2010 11:14 PM, Paolo Bonzini wrote:
> > > On 11/24/2010 05:50 PM, Christoph Hellwig wrote:
> > >> Btw, it might make sense
> > The commit message of this commit says it's a workaround for a problem
> > with lsi:
> >
> >> - when a read is aborted due to a mark/EOF/EOD/EOM, the len reported to
> >> controller can be 0. LSI controller emulation doesn't know how to manage
> >> this. A workaround found is to call the comp
> Yep, so it appears that commit 89c0f6438d16 did introduce the bogus
> 'double complete' in scsi_read_complete, which I think was intended to
> handle residual counts for TYPE_TYPE...
>
> /* Cancel a pending data transfer. */
> @@ -251,6 +257,8 @@ static void scsi_read_complete(void * opaque,
Hi folks !
There's an odd problem I've encountered with my scsi host (basically an
powerpc "vscsi" compatible with IBM PAPR).
When using /dev/sg (ie, scsi-generic), there seem to be no way I can
find to retrieve the underlying driver's max request transfer size.
This can normally be obtained wit
o
interrogate scsi-generic (and the underlying block driver) which is the
main issue (that plus the fact that the ioctl seems to be broken in
"compat" mode for /dev/sg specifically)...
Cheers,
Ben.
>
> regards
> ronnie sahlberg
>
>
> On Tue, Dec 21, 2010 at 2:25 PM
> > So back to square 1 ... my vscsi (and virtio-blk too btw) can
> > technically pass a max size to the guest, but we don't have a way to
> > interrogate scsi-generic (and the underlying block driver) which is the
> > main issue (that plus the fact that the ioctl seems to be broken in
> > "compat"
On Wed, 2010-12-22 at 14:54 +0100, Hannes Reinecke wrote:
> Well, sort of. 'sg' doesn't have any block queue limits directly as the
> block queue is attached to the block device (surprise, surprise :-).
> But nevertheless any commands send via SG_IO are being placed on the
> block queue, hence the
On Wed, 2010-12-22 at 14:27 +0100, Christoph Hellwig wrote:
> On Wed, Dec 22, 2010 at 02:54:54PM +0100, Hannes Reinecke wrote:
> > Most modern HBAs are using separate codepaths for streaming/block I/O
> > anyway,
>
> That's not true at all. Every normal HBA justs passes normal SCSI
> commands to
On Thu, 2010-12-23 at 00:23 +0100, Alexander Graf wrote:
> > The non working compat ioctl is one, the fact that "sg" has
> > no /sys/class/block (or /sys/block) entries is another, etc... Ie,
> we
> > are faced with a problem with Linux not exposing those informations
> in
> > an easy to retrieve w
On Thu, 2010-12-23 at 00:39 +0100, Alexander Graf wrote:
> This all belongs in the block layer. If you create a call back
> function or property in the block struct, windows can implement its
> own limits when someone sits down to implement SG_IO on Windows.
Right and we do have "generic" ways it
On Thu, 2010-12-23 at 00:49 +0100, Alexander Graf wrote:
>
> Congratulations for finding lots of Linux bugs :). Look at it from
> that way: You'll most likely be the very first person actually using
> sg properly. So after you're done, others won't have to fix it :).
Hahah, I doubt it :-) Makes m
Hi there,
we've been using qemu for quite a while on different platforms and we'd like to
perform snapshots on running qemu machines and tar them onto a backup server.
The qemu-img snapshot can only be applied to inactive qemu machines (images),
hence this is not applicable. The savevm command w
Public bug reported:
In several places, including the tcp migration code, qemu uses
gethostbyname and inet_aton to construct a sockaddr_in. These should be
replaced by the more modern getaddrinfo for both connect and accept,
along with a loop to try all returned addrinfo structs on the connecting
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 acces
Add support to the emulated hardware to insert vlan tags in packets
going from the guest to the network.
Signed-off-by: Benjamin Poirier
Cc: Igor V. Kovalenko
Cc: Jason Wang
Cc: Michael S. Tsirkin
---
hw/rtl8139.c | 102 ++
1 files
Add support to the emulated hardware to extract vlan tags in packets
going from the network to the guest.
Signed-off-by: Benjamin Poirier
Cc: Igor V. Kovalenko
Cc: Jason Wang
Cc: Michael S. Tsirkin
--
AFAIK, extraction is optional to get vlans working. The driver
requests rx detagging but
Here is version 5 of my patchset to add vlan support to the emulated rtl8139
nic.
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 unli
clean out ifdef's around ethernet checksum calculation
Signed-off-by: Benjamin Poirier
Cc: Igor V. Kovalenko
Cc: Jason Wang
Cc: Michael S. Tsirkin
Cc: Blue Swirl
---
hw/rtl8139.c | 20 +++-
1 files changed, 3 insertions(+), 17 deletions(-)
diff --git a/hw/rtl8139.c
Add support to the emulated hardware to insert vlan tags in packets
going from the guest to the network.
Signed-off-by: Benjamin Poirier
Cc: Igor V. Kovalenko
Cc: Jason Wang
Cc: Michael S. Tsirkin
Cc: Blue Swirl
---
hw/rtl8139.c | 107
Add support to the emulated hardware to extract vlan tags in packets
going from the network to the guest.
Signed-off-by: Benjamin Poirier
Cc: Igor V. Kovalenko
Cc: Jason Wang
Cc: Michael S. Tsirkin
Cc: Blue Swirl
--
AFAIK, extraction is optional to get vlans working. The driver
requests rx
clean out ifdef's around ethernet checksum calculation
Signed-off-by: Benjamin Poirier
Cc: Igor V. Kovalenko
Cc: Jason Wang
Cc: Michael S. Tsirkin
Cc: Blue Swirl
---
hw/rtl8139.c | 20 +++-
1 files changed, 3 insertions(+), 17 deletions(-)
diff --git a/hw/rtl8139.c
Here is version 6 of my patchset to add vlan support to the emulated rtl8139
nic.
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.
Add support to the emulated hardware to insert vlan tags in packets
going from the guest to the network.
Signed-off-by: Benjamin Poirier
Cc: Igor V. Kovalenko
Cc: Jason Wang
Cc: Michael S. Tsirkin
Cc: Blue Swirl
---
hw/rtl8139.c | 57
Add support to the emulated hardware to extract vlan tags in packets
going from the network to the guest.
Signed-off-by: Benjamin Poirier
Cc: Igor V. Kovalenko
Cc: Jason Wang
Cc: Michael S. Tsirkin
Cc: Blue Swirl
--
AFAIK, extraction is optional to get vlans working. The driver
requests rx
On Wed, 2011-03-16 at 17:03 +0100, Alexander Graf wrote:
>
> > +int spapr_tce_dma_zero(VIOsPAPRDevice *dev, uint64_t taddr,
> uint32_t size)
> > +{
> > +uint8_t *zeroes;
> > +
> > +#ifdef DEBUG_TCE
> > +fprintf(stderr, "spapr_tce_dma_zero taddr=0x%llx size=0x%x\n",
> > +(unsign
On Wed, 2011-03-16 at 17:41 +0100, Alexander Graf wrote:
> > +/*
> > + * Common MAD header
> > + */
> > +struct mad_common {
> > +uint32_t type;
> > +uint16_t status;
> > +uint16_t length;
> > +uint64_t tag;
>
> Is this an in-memory representation? If so, it should be packed, righ
On Wed, 2011-03-16 at 15:22 -0500, Anthony Liguori wrote:
>
> But BTW, if you're already being evil and using alloca, it's a whole
> lot
> nicer to just do:
>
> uint8_t zeros[size];
Right. I haven't written that bit of the code so I'll let David fix it
but it does indeed look nicer. Eventually,
On Thu, 2011-03-17 at 13:21 +1100, David Gibson wrote:
> > Is this an official extension used by anyone or is it your own
> > invention that's not implemented in pHyp?
>
> The latter.
The main reason is to avoid having to deal with TCEs in SLOF :-)
Cheers,
Ben.
On Thu, 2011-03-17 at 08:44 +0100, Alexander Graf wrote:
> On 17.03.2011, at 04:25, Benjamin Herrenschmidt
> wrote:
>
> > On Thu, 2011-03-17 at 13:21 +1100, David Gibson wrote:
> >>> Is this an official extension used by anyone or is it your own
> >>> i
clean out ifdef's around ethernet checksum calculation
Signed-off-by: Benjamin Poirier
Acked-by: Igor V. Kovalenko
Cc: Jason Wang
Cc: Michael S. Tsirkin
Cc: Blue Swirl
---
hw/rtl8139.c | 20 +++-
1 files changed, 3 insertions(+), 17 deletions(-)
diff --git a/hw/rtl8
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_receiv
Add support to the emulated hardware to extract vlan tags in packets
going from the network to the guest.
Signed-off-by: Benjamin Poirier
Cc: Igor V. Kovalenko
Cc: Jason Wang
Cc: Michael S. Tsirkin
Cc: Blue Swirl
--
AFAIK, extraction is optional to get vlans working. The driver
requests rx
Add support to the emulated hardware to insert vlan tags in packets
going from the guest to the network.
Signed-off-by: Benjamin Poirier
Cc: Igor V. Kovalenko
Cc: Jason Wang
Cc: Michael S. Tsirkin
Cc: Blue Swirl
---
hw/rtl8139.c | 75
On Wed, 2011-03-23 at 16:30 +1100, David Gibson wrote:
> +- SLOF (Slimline Open Firmware) is a free IEEE 1275 Open Firmware
> + implementation for certain IBM POWER hardware. The image currently
> + in qemu is built from git tag qemu-slof-20110323.
> +
For those who can't wait to check it out .
On Wed, 2011-03-23 at 19:51 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2011-03-23 at 16:30 +1100, David Gibson wrote:
> > +- SLOF (Slimline Open Firmware) is a free IEEE 1275 Open Firmware
> > + implementation for certain IBM POWER hardware. The image currently
> > +
On Wed, 2011-03-23 at 15:38 +0100, Alexander Graf wrote:
> On 23.03.2011, at 06:30, David Gibson wrote:
>
> > This patch series adds a "pseries" machine to qemu, allowing it to
> > emulate IBM pSeries logical partitions. More specifically it
> > implements the interface defined by the "PowerPC Ar
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 im
On Wed, 2011-03-23 at 22:29 +0100, Alexander Graf wrote:
> 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 :).
Hrm, something must have been broken then from last I touched it. I'll
have a look later today.
Cheers,
Ben.
On Thu, 2011-03-24 at 01:51 +1100, David Gibson wrote:
> Ah, you probably need to increase the amount of memory given to the
> guest. The SLOF image, certainly, won't work with the qemu default
> memory size. Try -m 512.
Ah good point, forgot about that. SLOF has a minimum of 256M due to the
way
On Wed, 2011-03-23 at 22:29 +0100, Alexander Graf wrote:
> > It should work. I've used my laptop with a 32-bit qemu iirc for a
> while
> > when working on SLOF... at least I -think- I did :-)
>
> 32-bit host or guest? I'm talking about --target-list=ppc-softmmu
Ohhh sorry, you are right, -M pseri
Hello,
commit 20ff075bb3340c5278a0da38ad1f4d602565aa06
Author: Michael Walle
Date: Mon Mar 7 23:32:39 2011 +0100
configure: add opengl detection
This patch introduce a new config option CONFIG_OPENGL.
Signed-off-by: Michael Walle
Signed-off-by: Edgar E. Iglesias
introduces
On Tue, 2011-04-05 at 14:14 +1000, David Gibson wrote:
> > >@@ -255,7 +255,7 @@ static int vscsi_srp_direct_data(VSCSIState *s,
> vscsi_req *req,
> > > {
> > > struct srp_direct_buf *md = req->cur_desc;
> > > uint32_t llen;
> > >-int rc;
> > >+int rc = 0;
> >
> > David, is this
On Mon, Apr 4, 2011 at 6:13 PM, Michael Walle wrote:
> Hi Benjamin,
>
>> Let me know if you need more info.
>
> what happens if you configure with
>
> ./configure --target-list=x86_64-softmmu --disable-opengl
>
Works as usual.
The problem I'm facing stems
On Sat, 2011-02-12 at 18:40 +0200, Blue Swirl wrote:
>
> sPAPREnvironment has a certain aroma reminding of aHungarian
> nNotation, but otherwise the bouquet is entirely passable.
It's just the smell, like a good french cheese :-)
sPAPR as "server Power Architecture® Platform Requirements",
whic
On Sat, 2011-02-12 at 18:59 +0200, Blue Swirl wrote:
>
> Actually I don't quite understand the need for vty layer, why not use
> the chardev here directly?
I'm not sure what you mean here...
Basically, the interface presented to guests is sPAPR compliant, so
virtual devices come with a bunch of
On Sun, 2011-02-13 at 00:52 +0200, Blue Swirl wrote:
> On Sat, Feb 12, 2011 at 11:00 PM, Benjamin Herrenschmidt
> wrote:
> > On Sat, 2011-02-12 at 18:59 +0200, Blue Swirl wrote:
> >>
> >> Actually I don't quite understand the need for vty layer, why not
On Sun, 2011-02-13 at 10:08 +0200, Blue Swirl wrote:
> This is a bit of a special case, much like semihosting modes for m68k
> or ARM, or like MOL hacks which were removed recently. From QEMU point
> of view, the most natural way of handling this would be hypervisor
> implemented in the guest side
On Sun, 2011-02-13 at 14:15 +0200, Blue Swirl wrote:
>
> Maybe it would be more complex but also emulation accuracy would be
> increased and the interfaces would be saner. We don't shortcut BIOS
> and implement its services to OS in QEMU for other machines either.
But that is not comparable. BIOS
On Sun, 2011-02-13 at 13:40 +0100, Alexander Graf wrote:
>
> We can surely move it to dynamic later on. I think the "proper" way
> would be to populate a qdev bus and have the individual hypercall
> receivers register themselves through -device creations. But Blue
> really is the expert here :).
On Sun, 2011-02-13 at 10:48 -0600, Anthony Liguori wrote:
>
> We try very, very hard to make our paravirtualization look like real
> hardware.
Sure, that makes sense when you invent new paravirt interfaces, but that
isn't the case. Note also that our current processors do not have the
ability to
On Sun, 2011-02-13 at 10:52 -0600, Anthony Liguori wrote:
>
> A virtual bus is just an interface. If all virtual devices that
> interact via hcalls would all reside on the same virtual bus, then
> having hypercalls registered through that interface makes sense
> because
> you can associate hyp
Signed-off-by: Benjamin Poirier
---
net.c | 28 ++--
1 files changed, 6 insertions(+), 22 deletions(-)
diff --git a/net.c b/net.c
index ec4745d..15ed40b 100644
--- a/net.c
+++ b/net.c
@@ -36,6 +36,7 @@
#include "qemu-common.h"
#include "qemu_socket.h
I've posted v2 of these patches back in november
http://article.gmane.org/gmane.comp.emulators.qemu/84252
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 rt
Add support to the emulated hardware to insert vlan tags in packets
going from the guest to the network.
Signed-off-by: Benjamin Poirier
Cc: Igor V. Kovalenko
Cc: Jason Wang
Cc: Michael S. Tsirkin
---
hw/rtl8139.c | 123 +-
1 files
Add support to the emulated hardware to extract vlan tags in packets
going from the network to the guest.
Signed-off-by: Benjamin Poirier
Cc: Igor V. Kovalenko
Cc: Jason Wang
Cc: Michael S. Tsirkin
--
AFAIK, extraction is optional to get vlans working. The driver
requests rx detagging but
mory, that
fixes the issue with my test program but I'm not sure if it's the proper
thing to do, or even if it works with other arm boards.
Rgds,
Benjamin
init.patch
Description: Binary data
mory, that
fixes the issue with my test program but I'm not sure if it's the proper
thing to do, or even if it works with other arm boards.
Rgds,
Benjamin
init.patch
Description: Binary data
Hi,
We applied the attached patch in Ubuntu to fix the wrong behavior of
caps lock.
Initial bug report: https://launchpad.net/bugs/427612
Testcase: Select German NEO 2 as keyboard layout and press "caps lock" +
"l". Then a "-" should appear instead of a "t&quo
This should avoid truncating the register name when debugging.
Signed-off-by: David Benjamin
---
hw/eepro100.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index 8734907..3676dc0 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -648,7
On Sun, 2009-12-20 at 19:01 +0100, Alexander Graf wrote:
>
> Yes. The Alpha for example used stock VGABIOSes. IIRC Sparc has its
> own graphics anyways and I don't know about the others, but I suspect
> they either use x86 VGABIOSes or no VGABIOSes.
>
> Macs are different though. IIRC they have a
On Sun, 2009-12-20 at 18:53 +, Blue Swirl wrote:
>
> Some Sun machines also had "ATY,Rage XL" cards but I don't know if
> they had special roms.
They would have similar f-code to the mac ones (ie. Tokenized forth for
Open Firmware).
However, in the case of qemu, I don't see much point in do
On Sun, 2010-01-03 at 21:27 +0100, Alexander Graf wrote:
> I think if unin_pci is the only user, it'd be better to do it hacky
> inside unin_pci.c. But if there's a chance there's another user, it'd
> be better to make it generic.
>
> Since this is the first time I ever stumbled across type 0 and
On Mon, 2010-01-04 at 13:07 +0200, Michael S. Tsirkin wrote:
> BTW, I think we really should think about the right way to address the
> swap/noswap issue without using a preprocessor. Maybe make pci host
> bridge explicitly specify whether to swap bytes? How about adding a
> field in PCIHostState
801 - 900 of 1367 matches
Mail list logo
