Miguel Di Ciurcio Filho wrote:
> Hello,
>
> This is a prototype suggestion. I mostly copied and pasted the code from
> net/dump.c into net.c and made some adjustments. There is no command line
> parsing involved yet, just the internals and small changes in net/tap.c and
> net/slirp.c do make the t
On Wed, Jul 14, 2010 at 01:36:49PM -0600, Alex Williamson wrote:
> If we've unregistered a memory area, we should avoid calling
> qemu_get_ram_ptr() on the left over phys_offset cruft in the
> slot array. Now that we support removing ramblocks, the
> phys_offset ram_addr_t can go away and cause a
On Thu, Jul 08, 2010 at 07:49:35PM +0300, Michael S. Tsirkin wrote:
> > For root bus:
> > - pci_host_bus_new()/pci_host_bus_new_inplace()
> > qbus style api. pci segment must be specified.
> > New code should use this.
>
> I'd prefer a simple _init which works like _inplace.
> Allocating memo
On Thursday 15 July 2010 23:39:36 Casey Leedom wrote:
> | From: Sheng Yang
> | Date: Wednesday, July 14, 2010 06:31 pm
> |
> | On Thursday 15 July 2010 02:01:29 Casey Leedom wrote:
> | > | From: Sheng Yang
> | > | Date: Tuesday, July 13, 2010 05:53 pm
> |
> | (Please use reply to all next time.
Signed-off-by: Miguel Di Ciurcio Filho
---
net/tap.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/tap.c b/net/tap.c
index 0147dab..5bd069b 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -442,6 +442,9 @@ int net_init_tap(QemuOpts *opts, Monitor *mon, const char
*name,
An empty environment is sometimes useful in user mode.
The new option provides it for linux-user and bsd-user
(darwin-user still has no environment related options).
The patch also adds the documentation for other
environment related options.
Signed-off-by: Stefan Weil
---
bsd-user/main.c |
Signed-off-by: Miguel Di Ciurcio Filho
---
net.c | 90 +
net.h |8 +
qemu-common.h |1 +
3 files changed, 99 insertions(+), 0 deletions(-)
diff --git a/net.c b/net.c
index 8ddf872..6f125f8 100644
--- a/net.c
++
Hello,
This is a prototype suggestion. I mostly copied and pasted the code from
net/dump.c into net.c and made some adjustments. There is no command line
parsing involved yet, just the internals and small changes in net/tap.c and
net/slirp.c do make the thing work.
In my tests, using tap as backe
Signed-off-by: Miguel Di Ciurcio Filho
---
net/slirp.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/slirp.c b/net/slirp.c
index b41c60a..5823699 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -240,6 +240,9 @@ static int net_slirp_init(VLANState *vlan, const char
Signed-off-by: Miguel Di Ciurcio Filho
---
net/dump.c | 21 -
net/dump.h | 21 +
2 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/net/dump.c b/net/dump.c
index 6db7ecf..8eebacd 100644
--- a/net/dump.c
+++ b/net/dump.c
@@ -34,27 +34,6 @@
David Ahern wrote:
>
> On 07/15/10 12:26, Stefan Hajnoczi wrote:
>> On Thu, Jul 15, 2010 at 5:09 PM, David Ahern wrote:
>>> Is it possible to run qemu with a netboot image -- something created by
>>> mknbi? If so any notes on how to do that?
>> Yes, QEMU ships with a gPXE network boot ROM. Previ
On 07/15/2010 01:51 PM, Aurelien Jarno wrote:
On Thu, Jul 15, 2010 at 01:43:28PM -0500, Justin M. Forbes wrote:
On Tue, Jul 13, 2010 at 12:19:21PM -0500, Brian Jackson wrote:
On Tuesday, July 13, 2010 12:01:22 pm Avi Kivity wrote:
On 07/13/2010 07:57 PM, Anthony Liguori wrote
On Thu, Jul 15, 2010 at 01:43:28PM -0500, Justin M. Forbes wrote:
> On Tue, Jul 13, 2010 at 12:19:21PM -0500, Brian Jackson wrote:
> > On Tuesday, July 13, 2010 12:01:22 pm Avi Kivity wrote:
> > > On 07/13/2010 07:57 PM, Anthony Liguori wrote:
> > > >> I'd like to see more frequent stable releases,
On 07/15/10 12:26, Stefan Hajnoczi wrote:
> On Thu, Jul 15, 2010 at 5:09 PM, David Ahern wrote:
>> Is it possible to run qemu with a netboot image -- something created by
>> mknbi? If so any notes on how to do that?
>
> Yes, QEMU ships with a gPXE network boot ROM. Previously it shipped
> with
On Tue, Jul 13, 2010 at 12:19:21PM -0500, Brian Jackson wrote:
> On Tuesday, July 13, 2010 12:01:22 pm Avi Kivity wrote:
> > On 07/13/2010 07:57 PM, Anthony Liguori wrote:
> > >> I'd like to see more frequent stable releases, at least if the stable
> > >> branch contains fixes to user-reported bugs
On Thu, Jul 15, 2010 at 5:09 PM, David Ahern wrote:
> Is it possible to run qemu with a netboot image -- something created by
> mknbi? If so any notes on how to do that?
Yes, QEMU ships with a gPXE network boot ROM. Previously it shipped
with a legacy Etherboot boot ROM.
You can use the -boot n
On 07/15/2010 12:10 PM, Kevin Wolf wrote:
Am 15.07.2010 18:20, schrieb Anthony Liguori:
I have another idea that I hope will solve the problem in a more
complete way. The fundamental issue is that it's impossible to probe
raw images reliably. We can probe qcow2, vmdk, etc but not raw.
So,
On 07/15/2010 11:45 AM, Eduard - Gabriel Munteanu wrote:
On Thu, Jul 15, 2010 at 07:45:06AM -0500, Anthony Liguori wrote:
No. PCI devices should never call cpu_physical_memory*.
PCI devices should call pci_memory*.
ISA devices should call isa_memory*.
All device memory accesses should go
On Thu, Jul 15, 2010 at 10:17:10AM -0700, Chris Wright wrote:
> * Avi Kivity (a...@redhat.com) wrote:
> >
> > For emulated device, it seems like we can ignore ATS completely, no?
>
> Not if you want to emulate an ATS capable device ;)
>
> Eariler upthread I said:
>
> IOW, if qemu ever had a d
* Avi Kivity (a...@redhat.com) wrote:
> On 07/15/2010 08:17 PM, Chris Wright wrote:
> >
> >>For emulated device, it seems like we can ignore ATS completely, no?
> >Not if you want to emulate an ATS capable device ;)
>
> What I meant was that the whole request translation, invalidate, dma
> using a
On Thu, Jul 15, 2010 at 08:02:05PM +0300, Avi Kivity wrote:
> For emulated device, it seems like we can ignore ATS completely, no?
An important use-case for emulation is software testing and caching of
iommu's is an important part that needs to be handled in software. For
this purpose it makes se
On 07/15/2010 08:17 PM, Chris Wright wrote:
For emulated device, it seems like we can ignore ATS completely, no?
Not if you want to emulate an ATS capable device ;)
What I meant was that the whole request translation, invalidate, dma
using a translated address thing is invisible t
* Avi Kivity (a...@redhat.com) wrote:
> On 07/15/2010 07:52 PM, Chris Wright wrote:
> >
> >>Really? Can you provide an documentation to support this claim?
> >>My impression is that there is no difference between translated and
> >>untranslated devices, and the translation is explicitly disabled by
* Chris Wright (chr...@sous-sol.org) wrote:
> * Paul Brook (p...@codesourcery.com) wrote:
> > > > The right approach IMHO is to convert devices to use bus-specific
> > > > functions to access memory. The bus specific functions should have
> > > > a device argument as the first parameter.
> > >
>
Am 15.07.2010 18:20, schrieb Anthony Liguori:
> I have another idea that I hope will solve the problem in a more
> complete way. The fundamental issue is that it's impossible to probe
> raw images reliably. We can probe qcow2, vmdk, etc but not raw.
>
> So, let's do the following: have raw_pro
On 07/15/2010 07:52 PM, Chris Wright wrote:
Really? Can you provide an documentation to support this claim?
My impression is that there is no difference between translated and
untranslated devices, and the translation is explicitly disabled by software.
ATS allows an I/O device to reques
* Paul Brook (p...@codesourcery.com) wrote:
> > > The right approach IMHO is to convert devices to use bus-specific
> > > functions to access memory. The bus specific functions should have
> > > a device argument as the first parameter.
> >
> > As for ATS, the internal api to handle the device's
On Thu, Jul 15, 2010 at 07:45:06AM -0500, Anthony Liguori wrote:
>
> No. PCI devices should never call cpu_physical_memory*.
>
> PCI devices should call pci_memory*.
>
> ISA devices should call isa_memory*.
>
> All device memory accesses should go through their respective buses.
> There can
On Wed, Jul 14, 2010 at 01:39:46PM -0300, Luiz Capitulino wrote:
> On Tue, 13 Jul 2010 21:01:33 -0300
> Marcelo Tosatti wrote:
>
> >
> > If ->write fails, declare migration status as MIG_STATE_ERROR.
> >
> > Also, in buffered_file.c, ->close the object in case of an
> > error.
> >
> > Fixes "m
On 07/15/2010 10:19 AM, Markus Armbruster wrote:
Anthony Liguori writes:
On 07/14/2010 01:43 PM, Christoph Hellwig wrote:
Err, strong NACK. Please don't start messing with the contents of the
data plane, we're getting into real trouble there. It's perfectly
valid for a guest to cr
Is it possible to run qemu with a netboot image -- something created by
mknbi? If so any notes on how to do that?
David
Anthony Liguori writes:
> On 07/14/2010 01:43 PM, Christoph Hellwig wrote:
>> Err, strong NACK. Please don't start messing with the contents of the
>> data plane, we're getting into real trouble there. It's perfectly
>> valid for a guest to create an image inside an image, and with hardware
>>
On Thu, Jul 15, 2010 at 10:35:46PM +0800, chen huacai wrote:
> Hi, Aurelien,
> Can qemu emulate mips target on mips host currently? When I
> emulate a malta (or fuloong) machine on my fuloong box, qemu crashes
> after booting kernel, before the init process. Crash messages may be
> "illegal ins
On Thu, Jul 15, 2010 at 11:49:20AM +0100, Paul Brook wrote:
> > An IOMMU is not necessarily part of a bus bridge. By concept an IOMMU
> > can also be implemented on a plugin-card translating only that card.
> > Real implementations that I am aware of always implement the IOMMU in
> > the PCI root
On Thu, Jul 15, 2010 at 07:45:06AM -0500, Anthony Liguori wrote:
> On 07/15/2010 04:10 AM, Joerg Roedel wrote:
>> If this means a seperate interface for device dma accesses and not fold
>> that functionality into the cpu_physical_memory* interface I agree too :-)
>>
> No. PCI devices should never
Hi, Aurelien,
Can qemu emulate mips target on mips host currently? When I
emulate a malta (or fuloong) machine on my fuloong box, qemu crashes
after booting kernel, before the init process. Crash messages may be
"illegal instruction", "segment fault" or "bus error". On x86 hosts
everything is O
> >>> Depending how the we decide to handle IOMMU invalidation, it may also
> >>> be necessary to augment the memory_map API to allow the system to
> >>> request a mapping be revoked. However this issue is not specific to
> >>> the IOMMU implementation. Such bugs are already present on any system
On Tue, Jul 13, 2010 at 7:47 PM, Rick Vernam wrote:
> On Wednesday 07 July 2010 13:57:48 Corentin Chary wrote:
>> This set contains all my patchs related to tight and threaded vnc server.
>>
>> Since v1:
>> * Add a fix for jpeg and png with non-24bpp displays
>> * Better default values for vnc opt
On Thu, Jul 15, 2010 at 1:57 PM, Anthony Liguori
wrote:
> On 07/15/2010 04:10 AM, Stefan Hajnoczi wrote:
>>
>> I have mixed feelings about this approach. It has good usability
>> because legitimate users are unaffected, but adding a check into the
>> I/O path is unfortunate from a clean code pers
Am 15.07.2010 14:57, schrieb Anthony Liguori:
> On 07/15/2010 04:10 AM, Stefan Hajnoczi wrote:
>> I think there are actually two issues here:
>>
>> 1. Confusing QEMU so it sees an image with a different format than expected.
>>
>> This is important because it's unexpected behavior for a user who pu
** Changed in: qemu-kvm (Ubuntu)
Importance: Undecided => Medium
** Changed in: qemu-kvm (Ubuntu)
Status: New => Triaged
--
qemu-system-arm segfaults emulating versatile machine after running debootstrap
--second-stage inside vm
https://bugs.launchpad.net/bugs/604872
You received this
Am 15.07.2010 14:50, schrieb Anthony Liguori:
> CVE-2008-2004 described a vulnerability in QEMU whereas a malicious user could
> trick the block probing code into accessing arbitrary files in a guest. To
> mitigate this, we added an explicit format parameter to -drive which disabling
> block probi
On 07/15/2010 04:10 AM, Stefan Hajnoczi wrote:
I have mixed feelings about this approach. It has good usability
because legitimate users are unaffected, but adding a check into the
I/O path is unfortunate from a clean code perspective.
Management stacks that don't explicitly set format= today a
CVE-2008-2004 described a vulnerability in QEMU whereas a malicious user could
trick the block probing code into accessing arbitrary files in a guest. To
mitigate this, we added an explicit format parameter to -drive which disabling
block probing.
Fast forward to today, and the vast majority of u
On 07/15/2010 07:44 AM, Kevin Wolf wrote:
Am 15.07.2010 14:28, schrieb Anthony Liguori:
On 07/15/2010 03:13 AM, Kevin Wolf wrote:
Am 14.07.2010 19:54, schrieb Anthony Liguori:
CVE-2008-2004 described a vulnerability in QEMU whereas a malicious user could
trick the block prob
On 07/15/2010 04:10 AM, Joerg Roedel wrote:
On Wed, Jul 14, 2010 at 04:29:18PM -0500, Anthony Liguori wrote:
On 07/14/2010 03:13 PM, Paul Brook wrote:
Well, ok, the function name needs fixing too. However I think the only thing
missing from the current API is that it does not provide
Am 15.07.2010 14:28, schrieb Anthony Liguori:
> On 07/15/2010 03:13 AM, Kevin Wolf wrote:
>> Am 14.07.2010 19:54, schrieb Anthony Liguori:
>>
>>> CVE-2008-2004 described a vulnerability in QEMU whereas a malicious user
>>> could
>>> trick the block probing code into accessing arbitrary files i
On 07/15/2010 05:33 AM, Paul Brook wrote:
Depending how the we decide to handle IOMMU invalidation, it may also be
necessary to augment the memory_map API to allow the system to request a
mapping be revoked. However this issue is not specific to the IOMMU
implementation. Such bugs are already pr
On 07/15/2010 04:20 AM, Daniel P. Berrange wrote:
On Wed, Jul 14, 2010 at 01:50:02PM -0500, Anthony Liguori wrote:
On 07/14/2010 01:43 PM, Christoph Hellwig wrote:
Err, strong NACK. Please don't start messing with the contents of the
data plane, we're getting into real trouble there.
On 07/15/2010 03:13 AM, Kevin Wolf wrote:
Am 14.07.2010 19:54, schrieb Anthony Liguori:
CVE-2008-2004 described a vulnerability in QEMU whereas a malicious user could
trick the block probing code into accessing arbitrary files in a guest. To
mitigate this, we added an explicit format parame
Коренберг Марк wrote:
> Patch was created and sent to developers by Jan Kiszka. (He does not
> love bugtrackers)
Patches have to go via the mailing list, not some bug tracker. That's
policy here just like in many other projects. Also, I didn't say I hate
bug trackers in general, just this one as d
> On Wed, Jul 14, 2010 at 02:53:03PM +0100, Paul Brook wrote:
> > > Memory accesses must go through the IOMMU layer.
> >
> > No. Devices should not know or care whether an IOMMU is present.
>
> They don't really care. iommu_get() et al. are convenience functions
> which can and do return NULL whe
> On Wed, Jul 14, 2010 at 09:13:44PM +0100, Paul Brook wrote:
> > A device performs a memory access on its local bus. It has no knowledge
> > of how that access is routed to its destination. The device should not
> > be aware of any IOMMUs, in the same way that it doesn't know whether it
> > happe
> > Depending how the we decide to handle IOMMU invalidation, it may also be
> > necessary to augment the memory_map API to allow the system to request a
> > mapping be revoked. However this issue is not specific to the IOMMU
> > implementation. Such bugs are already present on any system that all
> > The right approach IMHO is to convert devices to use bus-specific
> > functions to access memory. The bus specific functions should have
> > a device argument as the first parameter.
>
> As for ATS, the internal api to handle the device's dma reqeust needs
> a notion of a translated vs. an un
On Wed, Jul 14, 2010 at 09:13:44PM +0100, Paul Brook wrote:
> A device performs a memory access on its local bus. It has no knowledge of
> how
> that access is routed to its destination. The device should not be aware of
> any IOMMUs, in the same way that it doesn't know whether it happens to
On Wed, Jul 14, 2010 at 01:50:02PM -0500, Anthony Liguori wrote:
> On 07/14/2010 01:43 PM, Christoph Hellwig wrote:
> >Err, strong NACK. Please don't start messing with the contents of the
> >data plane, we're getting into real trouble there. It's perfectly
> >valid for a guest to create an image
Luiz Capitulino writes:
> On Tue, 13 Jul 2010 18:20:20 +0200
> Markus Armbruster wrote:
>
>> Luiz Capitulino writes:
>>
>> > On Tue, 13 Jul 2010 13:49:46 +0200
>> > Markus Armbruster wrote:
>> >
>> >> [cc: kraxel]
>> >>
>> >> I didn't get around to review v1. Sorry.
>> >>
>> >> Miguel Di C
On Wed, Jul 14, 2010 at 04:29:18PM -0500, Anthony Liguori wrote:
> On 07/14/2010 03:13 PM, Paul Brook wrote:
>> Well, ok, the function name needs fixing too. However I think the only thing
>> missing from the current API is that it does not provide a way to determine
>> which device is performing
On Thu, Jul 15, 2010 at 9:09 AM, Kevin Wolf wrote:
> Am 14.07.2010 20:43, schrieb Christoph Hellwig:
>> Err, strong NACK. Please don't start messing with the contents of the
>> data plane, we're getting into real trouble there. It's perfectly
>> valid for a guest to create an image inside an ima
On 3/1/10 10:19 PM, Maxim Kuvyrkov wrote:
The following series of 4 patches adds NPTL support for ColdFire
user-mode emulation and fixes several related issues, mainly in signal
handling.
0001-Add-NPTL-support-for-ColdFire.patch
Implement new kernel syscalls to support TLS storage and synchroniz
Am 14.07.2010 19:54, schrieb Anthony Liguori:
> CVE-2008-2004 described a vulnerability in QEMU whereas a malicious user could
> trick the block probing code into accessing arbitrary files in a guest. To
> mitigate this, we added an explicit format parameter to -drive which disabling
> block probi
Am 14.07.2010 20:43, schrieb Christoph Hellwig:
> Err, strong NACK. Please don't start messing with the contents of the
> data plane, we're getting into real trouble there. It's perfectly
> valid for a guest to create an image inside an image, and with hardware
> support for nested virtualization
Am 14.07.2010 19:40, schrieb Anthony Liguori:
> On 07/14/2010 11:42 AM, Kevin Wolf wrote:
>> However, I wonder why you even bother with adjusting buffers and
>> requests and stuff instead of just returning a straight -EIO. Doing so
>> would have the additional advantage that the expectation of the
Patch was created and sent to developers by Jan Kiszka. (He does not
love bugtrackers)
--
KVM segmentation fault, using SCSI+writeback and linux 2.4 guest
https://bugs.launchpad.net/bugs/595438
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to Q
65 matches
Mail list logo
