On Tue, Nov 03, 2009 at 04:09:16PM +0200, Michael S. Tsirkin wrote:
> > > Long term, we should fix all devices and *then* they can claim 64 bit
> > > support always. As a nice side effect, we'll be able to avoid
> > > rebuilding devices.
> >
> > Are you claiming that (PCI) devices emulation shoul
On Tue, Nov 03, 2009 at 03:45:12PM +0200, Michael S. Tsirkin wrote:
> > --- a/hw/pci_host.c
> > +++ b/hw/pci_host.c
> > @@ -32,6 +32,114 @@ do { printf("pci_host_data: " fmt , ## __VA_ARGS__); }
> > while (0)
> > #define PCI_DPRINTF(fmt, ...)
> > #endif
> >
> > +static void pci_host_config_wri
On (Tue) Nov 03 2009 [19:53:43], Jan Kiszka wrote:
> Amit Shah wrote:
> > On (Tue) Nov 03 2009 [23:25:52], Amit Shah wrote:
> >> On (Tue) Nov 03 2009 [18:08:57], Jan Kiszka wrote:
> >>> Amit Shah wrote:
> The initial_reset sent to chardevs doesn't do much other than setting
> a bool to tr
On Tue, Nov 03, 2009 at 03:35:12PM +0200, Michael S. Tsirkin wrote:
> On Tue, Nov 03, 2009 at 03:31:51PM +0200, Michael S. Tsirkin wrote:
> > On Fri, Oct 30, 2009 at 09:21:06PM +0900, Isaku Yamahata wrote:
> > > split static functions in pci_host.h into pci_host.c and
> > > pci_host_template.h.
> >
This series solves a problem that I've been struggling with for a few years now.
One of the best things about qemu is that it's possible to run guests as an
unprivileged user to improve security. However, if you want to have your guests
communicate with the outside world, you're pretty much forced
The page 108 of the SPARC Version 8 Architecture Manual describes
that addcc and addxcc shall compute carry flag the same way.
The page 110 claims the same about subcc and subxcc instructions.
This patch fixes carry computation in corner cases and removes redundant code.
The most visible effect of
There is absolutely no need to call reset functions when initializing
devices. Since we are already registering them, calling qemu_system_reset()
should suffice. Actually, it is what happens when we reboot the machine,
and using the same process instead of a special case semantics will even
allow u
This patch adds a helper that can be used to create a tap device attached to
a bridge device. Since this helper is minimal in what it does, it can be
given CAP_NET_ADMIN which allows qemu to avoid running as root while still
satisfying the majority of what users tend to want to do with tap devices
On Tue, Nov 03, 2009 at 06:05:13PM +0200, Avi Kivity wrote:
>>> cirrus has pretty good 2d acceleration. 3D is a mega-project though.
>>>
>> Cirrus has no blending/compositing hardware support.
>> Paravirtualized graphics can easily support full XRender-style
>> 2D acceleration.
>
> What do t
On Tue, Nov 03, 2009 at 11:38:18AM +0200, Avi Kivity wrote:
> On 11/03/2009 01:25 PM, Vincent Hanquez wrote:
> > not sure if i'm missing the point here, but couldn't it be hypothetically
> > extended to stuff 3d (or video& more 2d accel ?) commands too ? I can't
> > imagine the cirrus or stdvga dr
On 10/30/09 09:12, Hannes Reinecke wrote:
Gerd Hoffmann wrote:
http://repo.or.cz/w/qemu/kraxel.git?a=shortlog;h=refs/heads/scsi.v1
It is far from being completed, will continue tomorrow. Should give a
idea of the direction I'm heading to though. Comments welcome.
Yep, this looks good.
Mor
On Tue, Nov 3, 2009 at 8:50 PM, Glauber Costa wrote:
> There is absolutely no need to call reset functions when initializing
> devices. Since we are already registering them, calling qemu_system_reset()
> should suffice. Actually, it is what happens when we reboot the machine,
> and using the same
On Tue, Nov 03, 2009 at 12:24:15AM +0100, Alexander Graf wrote:
>> Also, we still need to keep the local frame buffer copy in sync so we
>> can mmap and read from it, right? So it's not really worth it
>> probably...
>
> But then again we could just try to be closer to a real graphics card.
> Wha
On Tue, Nov 3, 2009 at 10:03 PM, David Munday wrote:
> Hello,
> I am trying to run the blackscholes program from the PARSEC2.1 benchmark
> suite in QEMU SPARC user mode.
> In this case I am trying to run with just 2 threads. Unfortunately, when I
> try to run the program it hangs with the follow
On Tue, Nov 03, 2009 at 09:12:41PM +0100, Laurent Desnogues wrote:
> On Tue, Nov 3, 2009 at 8:50 PM, Glauber Costa wrote:
> > There is absolutely no need to call reset functions when initializing
> > devices. Since we are already registering them, calling qemu_system_reset()
> > should suffice. Ac
On Tue, Nov 3, 2009 at 9:16 PM, Glauber Costa wrote:
> On Tue, Nov 03, 2009 at 09:12:41PM +0100, Laurent Desnogues wrote:
>> On Tue, Nov 3, 2009 at 8:50 PM, Glauber Costa wrote:
>> > There is absolutely no need to call reset functions when initializing
>> > devices. Since we are already registeri
Hello,
I am trying to run the blackscholes program from the PARSEC2.1 benchmark suite
in QEMU SPARC user mode.
In this case I am trying to run with just 2 threads. Unfortunately, when I try
to run the program it hangs with the following prints:
HELPME: /mada/users/cromom/ESESC_PROJECT/esesc/emul
There is absolutely no need to call reset functions when initializing
devices. Since we are already registering them, calling qemu_system_reset()
should suffice. Actually, it is what happens when we reboot the machine,
and using the same process instead of a special case semantics will even
allow u
2009/9/19 Blue Swirl :
> Even Sparc32 can't boot Solaris for some mysterious reason.
Not so mysterious anymore! Mitch Bradley found that subcc instruction
was not correctly setting carry flag in the case where both arguments
were 0 and carry flag was previously set. Fixing the bug allowed to
star
Amit Shah wrote:
> On (Tue) Nov 03 2009 [23:25:52], Amit Shah wrote:
>> On (Tue) Nov 03 2009 [18:08:57], Jan Kiszka wrote:
>>> Amit Shah wrote:
The initial_reset sent to chardevs doesn't do much other than setting
a bool to true. Char devices are interested in the open event and
that
On 11/03/2009 05:05 PM, Avi Kivity wrote:
On 11/03/2009 05:29 PM, Ondrej Zajicek wrote:
On Tue, Nov 03, 2009 at 11:38:18AM +0200, Avi Kivity wrote:
On 11/03/2009 01:25 PM, Vincent Hanquez wrote:
not sure if i'm missing the point here, but couldn't it be
hypothetically
extended to stuff 3d (or
On (Tue) Nov 03 2009 [23:25:52], Amit Shah wrote:
> On (Tue) Nov 03 2009 [18:08:57], Jan Kiszka wrote:
> > Amit Shah wrote:
> > > The initial_reset sent to chardevs doesn't do much other than setting
> > > a bool to true. Char devices are interested in the open event and
> > > that gets sent whenev
On Tue, Nov 03, 2009 at 12:35:08PM -0200, Glauber Costa wrote:
> Right now, we issue cpu creation from the i/o thread, and then shoot a thread
> from inside that code. Over the last months, a lot of subtle bugs were
> reported,
> usually arising from the very fragile order of that initialization.
On Tue, Nov 03, 2009 at 03:46:07PM -0200, Marcelo Tosatti wrote:
> On Tue, Nov 03, 2009 at 12:35:08PM -0200, Glauber Costa wrote:
> > Right now, we issue cpu creation from the i/o thread, and then shoot a
> > thread
> > from inside that code. Over the last months, a lot of subtle bugs were
> > re
On (Tue) Nov 03 2009 [18:08:57], Jan Kiszka wrote:
> Amit Shah wrote:
> > The initial_reset sent to chardevs doesn't do much other than setting
> > a bool to true. Char devices are interested in the open event and
> > that gets sent whenever the device is opened.
>
> Have you checked with the moni
The ideal way to use qemu-bridge-helper is to give it an fscap of using:
setcap cap_net_admin=ep qemu-bridge-helper
Unfortunately, most distros still do not have a mechanism to package files
with fscaps applied. This means they'll have to SUID the qemu-bridge-helper
binary.
To improve security
On Tue, Nov 03, 2009 at 09:11:40AM -0500, Beth Kon wrote:
> Kevin O'Connor wrote:
>> When was this gpxe rom built? I know gpxe used to have an issue with
>> the checksum not being updated, but I thought that was fixed about six
>> months ago.
>>
> The rom was built about 2 weeks ago. But I don'
The most common use of -net tap is to connect a tap device to a bridge. This
requires the use of a script and running qemu as root in order to allocate a
tap device to pass to the script.
This model is great for portability and flexibility but it's incredibly
difficult to eliminate the need to ru
We go to great lengths to restrict ourselves to just cap_net_admin as an OS
enforced security mechanism. However, we further restrict what we allow users
to do to simply adding a tap device to a bridge interface by virtue of the fact
that this is the only functionality we expose.
This is not good
Kevin O'Connor wrote:
I traced this down, and it looks like there is a series of subtle bugs
that led to this situation.
The bug causing the boot to fail is that gPXE didn't update its
checksum. This was supposed to be fixed in gPXE commit f16668d, but
it looks like gPXE either regressed or the
Amit Shah wrote:
> The initial_reset sent to chardevs doesn't do much other than setting
> a bool to true. Char devices are interested in the open event and
> that gets sent whenever the device is opened.
Have you checked with the monitor in all use cases (dedicated & muxed
console, stdio & SDL co
When creating a snapshot we can run into the situation that the first disk
doesn't have a snapshot, but the second one does have one with the same name as
the new snapshot.
In this case, qemu doesn't recognize that there is a snapshot to be
overwritten, so it starts to save the new snapshot and er
Right now, we issue cpu creation from the i/o thread, and then shoot a thread
from inside that code. Over the last months, a lot of subtle bugs were reported,
usually arising from the very fragile order of that initialization.
I propose we rethink that a little. This is a patch that received basic
On 11/03/2009 05:29 PM, Ondrej Zajicek wrote:
On Tue, Nov 03, 2009 at 11:38:18AM +0200, Avi Kivity wrote:
On 11/03/2009 01:25 PM, Vincent Hanquez wrote:
not sure if i'm missing the point here, but couldn't it be hypothetically
extended to stuff 3d (or video& more 2d accel ?) command
On 11/03/2009 05:14 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 11/03/2009 10:26 AM, Alexander Graf wrote:
Exactly. In fact, I'm even scared to reboot mine because I might end
up in a 3270 terminal. The whole text only crap keeps people from
using this platform! And that's what I want to c
Avi Kivity wrote:
On 11/03/2009 10:26 AM, Alexander Graf wrote:
Exactly. In fact, I'm even scared to reboot mine because I might end
up in a 3270 terminal. The whole text only crap keeps people from
using this platform! And that's what I want to change here.
Ok. I oppose paravirtualization f
On Fri, Oct 30, 2009 at 09:21:25PM +0900, Isaku Yamahata wrote:
> This patch implements pci bridge filtering.
>
> TODO: currently almost all the map funcions assumes
> filtered_size == size and addr & ~(size - 1) == addr.
> However with bridge filtering, they aren't always true.
> Teach them such
On Fri, Oct 30, 2009 at 09:21:18PM +0900, Isaku Yamahata wrote:
> This patch adds common routines for pcie host bridge and pcie mmcfg.
> This will be used by q35 based chipset emulation.
>
> Signed-off-by: Isaku Yamahata
> ---
> Makefile.target |2 +-
> hw/hw.h | 11 +++
> hw/pci.c
This function sends out the OPENED event to backends that
have drive the chardevs. The 'reset' is now a historical
artifact and we can now just call the function for what it
is.
Signed-off-by: Amit Shah
---
console.c |2 +-
hw/baum.c |2 +-
qemu-char.c | 22 +++---
The initial_reset sent to chardevs doesn't do much other than setting
a bool to true. Char devices are interested in the open event and
that gets sent whenever the device is opened.
Moreover, the reset logic breaks as and when qemu's bh scheduling
changes.
Signed-off-by: Amit Shah
---
qemu-char
On Fri, Oct 30, 2009 at 09:21:24PM +0900, Isaku Yamahata wrote:
> split out device iteration logic from pci_for_each_device().
> factored out function, pci_for_each_device_under_bus() will be used later.
>
> Signed-off-by: Isaku Yamahata
> ---
> hw/pci.c | 21 ++---
> 1 files c
chardevs have a 'can_read' function via which backends specify
the amount of data they can receive. When can_read returns > 0,
apps can start sending data. However, each chardev driver here
allows a max. of 1k bytes inspite of the backend being able to
receive more.
The best we can do here is to a
Hello,
These patches, all independent of each other, make the char backend a
little better by removing the initial_reset handling that's unnecessary,
bump up the amount of data that's sent per write() call to 4k from the
current 1k and also renames the generic char open() command to reflect
reali
On Fri, Oct 30, 2009 at 09:21:22PM +0900, Isaku Yamahata wrote:
> - Only sets default subsystem id for header type 00.(normal header type)
> because header type 01 doesn't have subsystem id, and uses the register
> for other purpose. So setting default subsystem id doesn't make sense.
>
> - in
On Fri, Oct 30, 2009 at 09:21:21PM +0900, Isaku Yamahata wrote:
> When updated ROM expantion address of header type 0, it missed
> to update mappings.
> Add PCI_ROM_ADDRESS check whether to call pci_update_mappings()
> Also update pci mapping when PCI_ROM_ADDRESS1 is written for header type 1.
>
>
On Fri, Oct 30, 2009 at 09:21:20PM +0900, Isaku Yamahata wrote:
> clean up pci_default_write_config() by the range helper functions.
>
> Suggested by Michael S. Tsirkin
> Cc: Michael S. Tsirkin
> Signed-off-by: Isaku Yamahata
Acked-by: Michael S. Tsirkin
> ---
> hw/pci.c |8 ++--
>
On Fri, Oct 30, 2009 at 09:21:19PM +0900, Isaku Yamahata wrote:
> add helper function to check ranges overlap suggested by
> Michael S. Tsirkin .
> His original suggestion was to use [first, last], however I chosen
> to use offset, length pair, i.e. [offset, offset + length)
> because pci configura
On Fri, Oct 30, 2009 at 09:21:23PM +0900, Isaku Yamahata wrote:
> Remove one indentation of pci_update_mappings.
> Just for cosmetics, no logic change.
Good stuff. But since you are not afraid of churn for
cosmetics, let's fix a couple more nits?
> Signed-off-by: Isaku Yamahata
> ---
> hw/pci.c
On Fri, Oct 30, 2009 at 09:21:12PM +0900, Isaku Yamahata wrote:
> Since It can be retrieved from pci configuration space,
> the member is unnecessary.
>
> Signed-off-by: Isaku Yamahata
Acked-by: Michael S. Tsirkin
> ---
> hw/pci.c | 21 ++---
> 1 files changed, 10 insertions
On Tue, Nov 03, 2009 at 11:01:00PM +0900, Isaku Yamahata wrote:
> On Tue, Nov 03, 2009 at 02:39:06PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Nov 03, 2009 at 02:22:07PM +0200, Avi Kivity wrote:
> > > On 11/03/2009 01:47 PM, Michael S. Tsirkin wrote:
> > >>
> > >> If qemu is compiled with target
Kevin O'Connor wrote:
On Mon, Nov 02, 2009 at 05:22:00PM -0600, Anthony Liguori wrote:
Beth Kon wrote:
Serendipity allowed us to find this really easily, thanks to some old
builds lying around...
The following Seabios commit breaks gpxe boot with e1000:
[...]
Any thoughts
On Fri, Oct 30, 2009 at 09:21:15PM +0900, Isaku Yamahata wrote:
> Move pci host stuff from pci.c to pci_host.c.
> And add some comments.
> Later pcie host bridge functions will be defined in pcie_host.c
> not to bloat pci.c.
For consistency, should we also move declaration to appropriate header,
a
On Tue, Nov 03, 2009 at 02:39:06PM +0200, Michael S. Tsirkin wrote:
> On Tue, Nov 03, 2009 at 02:22:07PM +0200, Avi Kivity wrote:
> > On 11/03/2009 01:47 PM, Michael S. Tsirkin wrote:
> >>
> >> If qemu is compiled with target phys address size 32 bit, emulated
> >> devices can not support a 64 bit
On Fri, Oct 30, 2009 at 09:21:14PM +0900, Isaku Yamahata wrote:
> factor out the logic which converts io port address into pci device
> and offset in PCI configuration space.
>
> Signed-off-by: Isaku Yamahata
> ---
> hw/pci.c | 32 ++--
> 1 files changed, 18 inserti
On Fri, Oct 30, 2009 at 09:21:07PM +0900, Isaku Yamahata wrote:
> consolidate pci_config address access into pci_host.c
>
> Signed-off-by: Isaku Yamahata
> ---
> hw/apb_pci.c | 43 +-
> hw/grackle_pci.c | 45 +-
> hw/pci_host.c| 108
> +++
On Tue, Nov 03, 2009 at 08:08:25AM +0200, Avi Kivity wrote:
> On 11/03/2009 08:02 AM, Kevin O'Connor wrote:
>> On Tue, Nov 03, 2009 at 07:01:52AM +0200, Avi Kivity wrote:
>> --- a/src/paravirt.c
>> +++ b/src/paravirt.c
>> @@ -23,8 +23,7 @@ qemu_cfg_select(u16 f)
>> static void
>> qemu_cfg_read(
On Tue, Nov 03, 2009 at 03:31:51PM +0200, Michael S. Tsirkin wrote:
> On Fri, Oct 30, 2009 at 09:21:06PM +0900, Isaku Yamahata wrote:
> > split static functions in pci_host.h into pci_host.c and
> > pci_host_template.h.
> > Later a structures declared in pci_host.h, PCIHostState, will be used.
> >
On Fri, Oct 30, 2009 at 09:21:06PM +0900, Isaku Yamahata wrote:
> split static functions in pci_host.h into pci_host.c and
> pci_host_template.h.
> Later a structures declared in pci_host.h, PCIHostState, will be used.
> However pci_host.h doesn't allow to include itself easily. This patches
> addr
On Fri, Oct 30, 2009 at 09:21:02PM +0900, Isaku Yamahata wrote:
> use pci_set_word() for pci command register.
>
> Signed-off-by: Isaku Yamahata
Acked-by: Michael S. Tsirkin
> ---
> hw/pci.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/pci.c b/hw/pci.c
On Tue, Nov 03, 2009 at 02:39:06PM +0200, Michael S. Tsirkin wrote:
> On Tue, Nov 03, 2009 at 02:22:07PM +0200, Avi Kivity wrote:
> > On 11/03/2009 01:47 PM, Michael S. Tsirkin wrote:
> >>
> >> If qemu is compiled with target phys address size 32 bit, emulated
> >> devices can not support a 64 bit
On Tue, Nov 03, 2009 at 10:54:44AM +0100, Jan Kiszka wrote:
> We have a function for this which does not issue annoying warnings.
Acked-by: Riku Voipio
> Signed-off-by: Jan Kiszka
> ---
>
> configure |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/configure
On Tue, Nov 03, 2009 at 02:22:07PM +0200, Avi Kivity wrote:
> On 11/03/2009 01:47 PM, Michael S. Tsirkin wrote:
>>
>> If qemu is compiled with target phys address size 32 bit, emulated
>> devices can not support a 64 bit BAR. Therefore, according to PCI spec,
>> such devices should declare all BAR
On 11/03/2009 01:47 PM, Michael S. Tsirkin wrote:
If qemu is compiled with target phys address size 32 bit, emulated
devices can not support a 64 bit BAR. Therefore, according to PCI spec,
such devices should declare all BARs as 32 bit.
What happens if you take a PCI card that supports 6
On Tue, Nov 03, 2009 at 12:52:10PM +0900, Isaku Yamahata wrote:
> On Sun, Nov 01, 2009 at 06:07:30PM +0200, Michael S. Tsirkin wrote:
> > On Fri, Oct 30, 2009 at 09:21:11PM +0900, Isaku Yamahata wrote:
> > > implemented pci 64bit bar support.
> > > The tricky bit is pci_update_mapping().
> > > An O
On 11/03/2009 11:40 AM, Liran Schour wrote:
- Liran
Avi Kivity wrote on 02/11/2009 20:47:34:
On 11/02/2009 03:40 PM, lir...@il.ibm.com wrote:
This series adds support for live migration without shared storage,
means
copy the storage while migrating. It was tested with
Document the '-usbdevice thermometer' option.
---
qemu-options.hx |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index d78b738..6748875 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -396,6 +396,9 @@ or fake device.
@item net:@v
Emulate the Vernier Go!Temp USB thermometer
(see: http://www.vernier.com/go/gotemp.html)
used in Greg Kroah-Hartman's "Write a Real, Working, Linux Driver" talk.
The emulation is complete enough for gregkh's sample driver and
using the vendor supplied SDK through the in-kernel 'ldusb' module unde
Move USB HID request constants from hw/usb-hid.c to hw/usb.h
to allow other modules to use them.
Signed-off-by: Scott Tsai
---
hw/usb-hid.c | 20 ++--
hw/usb.h |8
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/hw/usb-hid.c b/hw/usb-hid.c
inde
Greg Kroah-Hartman has been giving a talk titled "Write a Real, Working, Linux
Driver"
for the past four years at various conferences. This patch series enables qemu
to emulate
the Vernier Go!Temp USB thermometer used in that talk.
This was motivated by experience from the FreedomHEC Taipei 200
We have a function for this which does not issue annoying warnings.
Signed-off-by: Jan Kiszka
---
configure |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index aa2cc43..b38353a 100755
--- a/configure
+++ b/configure
@@ -1580,7 +1580,7 @@ int m
- Liran
Avi Kivity wrote on 02/11/2009 20:47:34:
> On 11/02/2009 03:40 PM, lir...@il.ibm.com wrote:
> > This series adds support for live migration without shared storage,
means
> > copy the storage while migrating. It was tested with KVM. Supports 2
ways
> > to replicate the storage during migr
On 11/03/2009 01:25 PM, Vincent Hanquez wrote:
not sure if i'm missing the point here, but couldn't it be hypothetically
extended to stuff 3d (or video& more 2d accel ?) commands too ? I can't
imagine the cirrus or stdvga driver be able to do that ever ;)
cirrus has pretty good 2d accelera
On Tue, Nov 03, 2009 at 07:39:34AM +0100, Alexander Graf wrote:
>
> On 03.11.2009, at 07:34, Avi Kivity wrote:
>
>> On 11/03/2009 08:27 AM, Alexander Graf wrote:
>>>
How does it work today?
>>>
>>> You boot into a TERM=dumb line based emulation on 3270 (worst thing
>>> haunting people's nigh
On 11/02/2009 10:23 PM, Alexander Graf wrote:
Any progress on the patch? This is really important to make KVM work
properly on S390. I'd even go as far as suggesting it for linux-stable.
I forgot all about it, sorry. Marcelo, can you commit it?
--
error compiling committee.c: too many ar
On 11/03/2009 10:26 AM, Alexander Graf wrote:
Exactly. In fact, I'm even scared to reboot mine because I might end
up in a 3270 terminal. The whole text only crap keeps people from
using this platform! And that's what I want to change here.
Ok. I oppose paravirtualization for its own sake and
On 03.11.2009, at 09:20, Avi Kivity wrote:
On 11/03/2009 09:50 AM, Alexander Graf wrote:
Ok, imagine this was not this unloved S390 odd architecture but
X86. The only output choices you have are:
1) virtio-console
2) VNC / SSH over network
3) virtio-fb
Now you want to configure a server,
On 11/03/2009 09:50 AM, Alexander Graf wrote:
Ok, imagine this was not this unloved S390 odd architecture but X86.
The only output choices you have are:
1) virtio-console
2) VNC / SSH over network
3) virtio-fb
Now you want to configure a server, probably using yast and all those
nice graphi
77 matches
Mail list logo
