> Why not just bypass the whole config file idea and just use enviornment
> variables?
Absolutely not. Environment variables are a horrid way of configuring things.
Paul
-
This SF.net email is sponsored by: Microsoft
Defy
andrzej zaborowski writes ("Re: [Qemu-devel] Re: [PATCH] Add support for a
configuration file"):
> What I'd love, though, but expect others will consider bloat, is that
> files are passed through cpp before interpreting.
cpp is a terrible preprocessor. It mostly works for C source code
(although
Le jeudi 15 mai 2008 à 15:04 +0300, Avi Kivity a écrit :
> Daniel P. Berrange wrote:
> > On Thu, May 15, 2008 at 11:04:47AM +0300, Avi Kivity wrote:
> >
> >> Daniel P. Berrange wrote:
> >>
> >>> With this kind of syntax, now tools generating config files need to make
> >>> up unique names f
Daniel P. Berrange wrote:
> On Thu, May 15, 2008 at 11:04:47AM +0300, Avi Kivity wrote:
>
>> Daniel P. Berrange wrote:
>>
>>> With this kind of syntax, now tools generating config files need to make
>>> up unique names for each drive. So you'll probably end up with them just
>>> naming thin
On Thu, May 15, 2008 at 11:04:47AM +0300, Avi Kivity wrote:
> Daniel P. Berrange wrote:
> >With this kind of syntax, now tools generating config files need to make
> >up unique names for each drive. So you'll probably end up with them just
> >naming things based on the class name + a number appende
Daniel P. Berrange wrote:
> With this kind of syntax, now tools generating config files need to make
> up unique names for each drive. So you'll probably end up with them just
> naming things based on the class name + a number appended.
>
I would hope that tools don't have to resort to reading
Paul Brook wrote:
>> I suggested it because my original plan for the configuration file was
>> based on this syntax with a strong inspiration from the OpenFirmware
>> device tree. The idea was that the object name ("drive" here) had no
>> hardcoded meaning, except for some predefined object names i
On Wed, 14 May 2008, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 14 May 2008, Javier Guerra wrote:
>
>> On Wed, May 14, 2008 at 10:13 AM, Johannes Schindelin
>> <[EMAIL PROTECTED]> wrote:
>>> On Wed, 14 May 2008, Javier Guerra wrote:
>>> > What about Lua? (http://www.lua.org)
>>> >
>>> > it sta
On Wed, May 14, 2008 at 10:37 AM, Johannes Schindelin
<[EMAIL PROTECTED]> wrote:
> On Wed, 14 May 2008, Javier Guerra wrote:
> > when embedded, you get to choose what libraries are available. there
> > are several examples of fairly secure settings.
>
> Why artificially make it complicated, and
Hi,
On Wed, 14 May 2008, Javier Guerra wrote:
> On Wed, May 14, 2008 at 10:13 AM, Johannes Schindelin
> <[EMAIL PROTECTED]> wrote:
> > On Wed, 14 May 2008, Javier Guerra wrote:
> > > What about Lua? (http://www.lua.org)
> > >
> > > it started up as a configuration language, and evolved into
On Wed, May 14, 2008 at 10:13 AM, Johannes Schindelin
<[EMAIL PROTECTED]> wrote:
> On Wed, 14 May 2008, Javier Guerra wrote:
> > What about Lua? (http://www.lua.org)
> >
> > it started up as a configuration language, and evolved into a full
> > programming language, while remaining _very_ lig
On Wed, May 14, 2008 at 09:45:02AM -0500, Javier Guerra wrote:
> What about Lua? (http://www.lua.org)
>
> it started up as a configuration language, and evolved into a full
> programming language, while remaining _very_ light (less than 200K
> with all libraries), and wonderfully easy to embed in
On Wednesday 14 May 2008, Anthony Liguori wrote:
> Paul Brook wrote:
> >> the "class" field is used to select the device model. Then all the other
> >> parameters are used to initialize the device model. That way it is
> >> possible to keep the compatibility with the existing options and add a
> >>
Dor Laor wrote:
> On Wed, 2008-05-14 at 17:41 +0300, Avi Kivity wrote:
>
> Please don't jump over me but I think it is worth mentioning OVF, at
> least for to know what's you opinions.
>
> Open Virtualization Format -
> http://www.vmware.com/appliances/learn/ovf.html
>
> It's xml based, supporte
Hi,
On Wed, 14 May 2008, Javier Guerra wrote:
> What about Lua? (http://www.lua.org)
>
> it started up as a configuration language, and evolved into a full
> programming language, while remaining _very_ light (less than 200K
> with all libraries), and wonderfully easy to embed into C programs.
Hi,
On Wed, 14 May 2008, andrzej zaborowski wrote:
> What I'd love, though, but expect others will consider bloat, is that
> files are passed through cpp before interpreting.
This will add a dependency to a developer's tool on an application that
has not much to do with development for most use
Paul Brook wrote:
>> the "class" field is used to select the device model. Then all the other
>> parameters are used to initialize the device model. That way it is
>> possible to keep the compatibility with the existing options and add a
>> provision to instanciate arbitrary new device models, such
On Wed, May 14, 2008 at 05:52:56PM +0300, Dor Laor wrote:
>
> On Wed, 2008-05-14 at 17:41 +0300, Avi Kivity wrote:
> > Daniel P. Berrange wrote:
> > > That's very nearly YAML format[1], which is attractive because parsers
> > > are available in every major programming language, and it is still
> >
Avi Kivity wrote:
> Daniel P. Berrange wrote:
>> That's very nearly YAML format[1], which is attractive because parsers
>> are available in every major programming language, and it is still
>> pretty human friendly.
>>
>> So my preference would be to go with the last option and make sure
>> it real
On Wed, 2008-05-14 at 17:41 +0300, Avi Kivity wrote:
> Daniel P. Berrange wrote:
> > That's very nearly YAML format[1], which is attractive because parsers
> > are available in every major programming language, and it is still
> > pretty human friendly.
> >
> > So my preference would be to go with
What about Lua? (http://www.lua.org)
it started up as a configuration language, and evolved into a full
programming language, while remaining _very_ light (less than 200K
with all libraries), and wonderfully easy to embed into C programs.
it lets you write things like:
drives = {
hda = {if='s
Daniel P. Berrange wrote:
> That's very nearly YAML format[1], which is attractive because parsers
> are available in every major programming language, and it is still
> pretty human friendly.
>
> So my preference would be to go with the last option and make sure
> it really is YAML compliant so pe
On 14/05/2008, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> Anthony Liguori wrote:
>
> > I think this is pretty useful as-is. I think it also gives us a
> reasonable
> > way to move forward that will keep everyone pretty happy.
> >
> > Here's a short example:
> >
> > qemu-system-x86_64 -hda ~/imag
> I suggested it because my original plan for the configuration file was
> based on this syntax with a strong inspiration from the OpenFirmware
> device tree. The idea was that the object name ("drive" here) had no
> hardcoded meaning, except for some predefined object names in order to
> keep a ki
Fabrice Bellard wrote:
> Avi Kivity wrote:
>> Fabrice Bellard wrote:
>>>
>>> I prefer:
>>>
>>> drive.file=foo.img
>>> drive.if=scsi
>>>
>>
>> That doesn't support multiple drives very well.
>
> Right, I realized it afterwards !
>
> I suggested it because my original plan for the configuration file
On Wed, May 14, 2008 at 02:26:40PM +0200, Fabrice Bellard wrote:
> Avi Kivity wrote:
> > Fabrice Bellard wrote:
> >>
> >> I prefer:
> >>
> >> drive.file=foo.img
> >> drive.if=scsi
> >>
> >
> > That doesn't support multiple drives very well.
>
> Right, I realized it afterwards !
>
> I suggested i
Avi Kivity wrote:
> Fabrice Bellard wrote:
>>
>> I prefer:
>>
>> drive.file=foo.img
>> drive.if=scsi
>>
>
> That doesn't support multiple drives very well.
Right, I realized it afterwards !
I suggested it because my original plan for the configuration file was
based on this syntax with a strong
Fabrice Bellard wrote:
>
> I prefer:
>
> drive.file=foo.img
> drive.if=scsi
>
That doesn't support multiple drives very well.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored
> That's very nearly YAML format[1], which is attractive because parsers
> are available in every major programming language, and it is still
> pretty human friendly.
While YAML is certainly human readable, it's not very "human writable" IMHO. I
think that a simpler format would be more appropiat
Anthony Liguori wrote:
> One thought I had, is that it would be very nice to break up the -drive
> file=foo.img,if=scsi syntax within the config file. In general, I'm
> thinking something like:
>
> [drive]
> file=foo.img
> if=scsi
>
> or:
>
> drive {
> file=foo.img
> if=scsi
> }
>
> or e
Dor Laor wrote:
> On Thu, 2008-05-08 at 12:03 +0200, Nicolas Daneau wrote:
>> Hi,
>>
>> I saw there was an active discussion about pci passthrough support in
>> KVM. I'm not a Dev, only a sys admin that need this support. As i saw
>> on the KVM home page that this feature is plan for 2H2008 in the
On Thu, May 08, 2008 at 05:02:28PM +0300, Eren T?rkay wrote:
> Hello,
>
> An advisory about $subject was released today by secunia. The security flaw
> was fixed in QEmu SVN repository.
>
> Kvm uses some of the old version of qemu that I can't backport patch I
> grabbed
> from qemu svn reposit
On 08 May 2008 Thu 17:12:14 Daniel P. Berrange wrote:
> If you look at the KVM userspace code you'll see this patch is already
> included:
>
> http://git.kernel.org/?p=virt/kvm/kvm-userspace.git;a=commit;h=ce486fc1116e
>b53d40635be926bfa147ad520908
Thank you, I'll grab the patch and apply it to ta
Hello,
An advisory about $subject was released today by secunia. The security flaw
was fixed in QEmu SVN repository.
Kvm uses some of the old version of qemu that I can't backport patch I grabbed
from qemu svn repository. Could you look at this issue and provide a patch?
http://secunia.com/adv
Marcelo Tosatti wrote:
> Slots 9 and 25 were using the identifier of the previous slot.
>
>
Applied, thanks.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by the 2008 Ja
Slots 9 and 25 were using the identifier of the previous slot.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index d2e33f4..c145c4b 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -269,10 +269,10 @@ DefinitionBlock (
On Wed, Apr 30, 2008 at 05:04:19PM -0300, Glauber Costa wrote:
> There is no reason why should i386 and x86_64 code for rdtsc be different.
> Unify them.
This makes the generated i386 assembly code far more complex (21
instructions instead of 5).
> ---
> cpu-all.h | 11 +--
> 1 files
Paul Brook wrote:
>>> Maybe 'VCPU' would be a clearer name? QEMU provides its own VCPU, and
>>> KQEMU+QEMU also provide one toegether. While KVM provides essentially
>>> one or more whole VCPUs by itself and uses QEMU's drivers only doesn't
>>> it?
>>>
>>> -- Jamie
>> VCPU is rather confusing wit
> > Maybe 'VCPU' would be a clearer name? QEMU provides its own VCPU, and
> > KQEMU+QEMU also provide one toegether. While KVM provides essentially
> > one or more whole VCPUs by itself and uses QEMU's drivers only doesn't
> > it?
> >
> > -- Jamie
>
> VCPU is rather confusing with the vcpus thems
Jamie Lokier wrote:
> Glauber Costa wrote:
>> This patch introduces QEMUAccel, a placeholder for function pointers
>> that aims at helping qemu to abstract accelerators such as kqemu and
>> kvm (actually, the 'accelerator' name was proposed by avi kivity, since
>> he loves referring to kvm that way
Glauber Costa wrote:
> This patch introduces QEMUAccel, a placeholder for function pointers
> that aims at helping qemu to abstract accelerators such as kqemu and
> kvm (actually, the 'accelerator' name was proposed by avi kivity, since
> he loves referring to kvm that way).
Just a little thought.
Avi Kivity wrote:
> David Abrahams wrote:
>> Jon gmail.com> writes:
>>
>>
>>> I use:
>>>
>>> export QEMU_AUDIO_DRV=alsa
>>> export QEMU_AUDIO_DAC_FIXED_FREQ=48000
>>> export QEMU_AUDIO_ADC_FIXED_FREQ=48000
>>> export QEMU_ALSA_DAC_BUFFER_SIZE=16384
>>>
>>> Buffer size is very important, else it
Daniel P. Berrange wrote:
> > > 2/ two instances of kvm can be passed the same -hda. There is no locking
> > > whatsoever. This messes up things seriously.
>
> That depends entirely on what you are doing with the disk in the guest OS.
>
> The disk could be hosting a cluster filesystem. The guest
David Abrahams wrote:
> Jon gmail.com> writes:
>
>
>> I use:
>>
>> export QEMU_AUDIO_DRV=alsa
>> export QEMU_AUDIO_DAC_FIXED_FREQ=48000
>> export QEMU_AUDIO_ADC_FIXED_FREQ=48000
>> export QEMU_ALSA_DAC_BUFFER_SIZE=16384
>>
>> Buffer size is very important, else it crackles and pops for me.
>>
Jon gmail.com> writes:
>
> I use:
>
> export QEMU_AUDIO_DRV=alsa
> export QEMU_AUDIO_DAC_FIXED_FREQ=48000
> export QEMU_AUDIO_ADC_FIXED_FREQ=48000
> export QEMU_ALSA_DAC_BUFFER_SIZE=16384
>
> Buffer size is very important, else it crackles and pops for me.
Unfortunately with my upgrade to Ubu
On 29/04/2008, Glauber Costa <[EMAIL PROTECTED]> wrote:
> This patch goes towards the direction of increasing general modularity of the
> code. Code in vl.c that used to live inside target ifdefs, are moved to
> inside the
> target directories, in a new file called machine.c. They are the cpu
>
On Apr 25, 2008, at 10:39 PM, Marcelo Tosatti wrote:
> On Fri, Apr 25, 2008 at 11:38:21AM +0200, Alexander Graf wrote:
>>
>> On Apr 25, 2008, at 3:01 AM, Marcelo Tosatti wrote:
>>
>>>
>>> Add three PCI bridges to support 128 slots. Vendor and device_id
>>> have
>>> been stolen from my test box.
On Fri, Apr 25, 2008 at 11:38:21AM +0200, Alexander Graf wrote:
>
> On Apr 25, 2008, at 3:01 AM, Marcelo Tosatti wrote:
>
> >
> >Add three PCI bridges to support 128 slots. Vendor and device_id have
> >been stolen from my test box.
> >
> >I/O port addresses behind each bridge are statically alloc
On Sat, Apr 19, 2008 at 6:11 PM, Glauber Costa <[EMAIL PROTECTED]> wrote:
>
> On Fri, Apr 18, 2008 at 1:27 PM, Avi Kivity <[EMAIL PROTECTED]> wrote:
> >
> > Glauber de Oliveira Costa wrote:
> >
> > > Hi,
> > > I've got some qemu crashes while trying to passthrough an ide device
> > > to a kvm
On 4/22/08, Alexander Graf <[EMAIL PROTECTED]> wrote:
> I believe that's the way to go. If you have spare time on your hands, feel
> free to integrate my multiboot patches as well.
>
OK, that looks straightforward enough.
Thanks,
Q
>
> On Apr 22, 2008, at 11:07 AM, Nguyen Anh Quynh wrote:
>
>
>
On Tue, Apr 22, 2008 at 3:10 AM, Avi Kivity <[EMAIL PROTECTED]> wrote:
> I'm rooting for btrfs myself.
but could btrfs (when stable) work for migration? i'm curious about
OCFS2 performance on this kind of load...
when i manage to sell the idea of a KVM cluster i'd like to know if i
should try f
Avi Kivity wrote:
> >And video streaming on some embedded devices with no MMU! (Due to the
> >page cache heuristics working poorly with no MMU, sustained reliable
> >streaming is managed with O_DIRECT and the app managing cache itself
> >(like a database), and that needs AIO to keep the request qu
Avi Kivity wrote:
> >Perhaps. This raises another point about AIO vs. threads:
> >
> >If I submit sequential O_DIRECT reads with aio_read(), will they enter
> >the device read queue in the same order, and reach the disk in that
> >order (allowing for reordering when worthwhile by the elevator)?
>
Avi Kivity wrote:
> Anthony Liguori wrote:
> >>If I submit sequential O_DIRECT reads with aio_read(), will they enter
> >>the device read queue in the same order, and reach the disk in that
> >>order (allowing for reordering when worthwhile by the elevator)?
> >>
> >There's no guarantee that any
Anthony Liguori wrote:
> >Perhaps. This raises another point about AIO vs. threads:
> >
> >If I submit sequential O_DIRECT reads with aio_read(), will they enter
> >the device read queue in the same order, and reach the disk in that
> >order (allowing for reordering when worthwhile by the elevator
Anthony Liguori wrote:
>>
>> If I submit sequential O_DIRECT reads with aio_read(), will they enter
>> the device read queue in the same order, and reach the disk in that
>> order (allowing for reordering when worthwhile by the elevator)?
>>
>
> There's no guarantee that any sort of order will b
Jamie Lokier wrote:
> Avi Kivity wrote:
>
>>> And video streaming on some embedded devices with no MMU! (Due to the
>>> page cache heuristics working poorly with no MMU, sustained reliable
>>> streaming is managed with O_DIRECT and the app managing cache itself
>>> (like a database), and that n
Le mardi 22 avril 2008 à 08:50 -0500, Anthony Liguori a écrit :
> Nguyen Anh Quynh wrote:
> > Hi,
> >
> > This should be submitted to upstream (but not to kvm-devel list), but
> > this is only the test code that I want to quickly send out for
> > comments. In case it looks OK, I will send it to up
Jamie Lokier wrote:
> Avi Kivity wrote:
>
>>> And video streaming on some embedded devices with no MMU! (Due to the
>>> page cache heuristics working poorly with no MMU, sustained reliable
>>> streaming is managed with O_DIRECT and the app managing cache itself
>>> (like a database), and that n
I believe that's the way to go. If you have spare time on your hands,
feel free to integrate my multiboot patches as well.
Alex
On Apr 22, 2008, at 11:07 AM, Nguyen Anh Quynh wrote:
> Hi,
>
> I am thinking about comibing this ROM with the extboot. Both two ROM
> are about "booting", so I think
Jamie Lokier wrote:
> Avi Kivity wrote:
>
>>> At such a tiny difference, I'm wondering why Linux-AIO exists at all,
>>> as it complicates the kernel rather a lot. I can see the theoretical
>>> appeal, but if performance is so marginal, I'm surprised it's in
>>> there.
>>>
>> Linux aio ex
Avi Kivity wrote:
> >At such a tiny difference, I'm wondering why Linux-AIO exists at all,
> >as it complicates the kernel rather a lot. I can see the theoretical
> >appeal, but if performance is so marginal, I'm surprised it's in
> >there.
>
> Linux aio exists, but that's all that can be said fo
Javier Guerra Giraldez wrote:
> On Sunday 20 April 2008, Avi Kivity wrote:
>
>> Also, I'd presume that those that need 10K IOPS and above will not place
>> their high throughput images on a filesystem; rather on a separate SAN LUN.
>>
>
> i think that too; but still that LUN would be access
Jamie Lokier wrote:
> Avi Kivity wrote:
>
>>> Does that mean "for the majority of deployments, the slow version is
>>> sufficient. The few that care about performance can use Linux AIO?"
>>>
>> In essence, yes. s/slow/slower/ and s/performance/ultimate block device
>> performance/.
>>
>
On Sunday 20 April 2008, Avi Kivity wrote:
> Also, I'd presume that those that need 10K IOPS and above will not place
> their high throughput images on a filesystem; rather on a separate SAN LUN.
i think that too; but still that LUN would be accessed by the VM's via one of
these IO emulation laye
Avi Kivity wrote:
> >Does that mean "for the majority of deployments, the slow version is
> >sufficient. The few that care about performance can use Linux AIO?"
>
> In essence, yes. s/slow/slower/ and s/performance/ultimate block device
> performance/.
>
> Many deployments don't care at all abou
Blue Swirl wrote:
> On 4/19/08, Anthony Liguori <[EMAIL PROTECTED]> wrote:
>
> Well, the IOVector part and bdrv_readv look OK, except for the heavy
> mallocing involved.
>
I don't think that in practice, malloc is going to have any sort of
performance impact. If it does, it's easy enough t
Jamie Lokier wrote:
> Avi Kivity wrote:
>
>> For the majority of deployments posix aio should be sufficient. The few
>> that need something else can use Linux aio.
>>
>
> Does that mean "for the majority of deployments, the slow version is
> sufficient. The few that care about performanc
Avi Kivity wrote:
> For the majority of deployments posix aio should be sufficient. The few
> that need something else can use Linux aio.
Does that mean "for the majority of deployments, the slow version is
sufficient. The few that care about performance can use Linux AIO?"
I'm under the impre
Marcelo Tosatti wrote:
> Now that threads are spinned up before machine->init(), clearing
> of HF_HALTED_MASK for irqchip in kernel case needs to be moved
> to actual vcpu startup.
>
Applied, thanks.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
On 4/19/08, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> Blue Swirl wrote:
>
> > On 4/17/08, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> >
> >
> > > Yes, the vector version of packet receive is tough. I'll take a look
> at
> > > your patch. Basically, you need to associate a set of RX vectors w
On Fri, Apr 18, 2008 at 1:27 PM, Avi Kivity <[EMAIL PROTECTED]> wrote:
>
> Glauber de Oliveira Costa wrote:
>
> > Hi,
> > I've got some qemu crashes while trying to passthrough an ide device
> > to a kvm guest. After some investigation, it turned out that
> register_ioport_{read/write} will abort o
Blue Swirl wrote:
> On 4/17/08, Anthony Liguori <[EMAIL PROTECTED]> wrote:
>
>> Yes, the vector version of packet receive is tough. I'll take a look at
>> your patch. Basically, you need to associate a set of RX vectors with each
>> VLANClientState and then when it comes time to deliver a pac
On 4/17/08, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> Yes, the vector version of packet receive is tough. I'll take a look at
> your patch. Basically, you need to associate a set of RX vectors with each
> VLANClientState and then when it comes time to deliver a packet to the VLAN,
> before ca
Anthony Liguori wrote:
> Right now, not specifying the -aio option is equivalent to your proposed
> -aio auto.
>
> I guess I should include an info aio to let the user know what type of
> aio they are using. We can add selection criteria later but
> semantically, not specifying an explicit -aio
Anthony Liguori wrote:
> >I'm of the view that '-aio auto' would be a really good option - and
> >when it's proven itself, it should be the default. It could work on
> >all QEMU hosts: it would pick synchronous IO when there is nothing else.
>
> Right now, not specifying the -aio option is equiva
Jamie Lokier wrote:
>> I've basically got a choice of making libvirt always ad '-aio linux'
>> or never add it at all. My inclination is to the latter since it is
>> compatible with existing QEMU which has no -aio option. Presumably
>> '-aio linux' is intended to provide some performance benefit so
Daniel P. Berrange wrote:
> > Those cases aren't always discoverable. Linux-aio just falls back to
> > using synchronous IO. It's pretty terrible. We need a new AIO
> > interface for Linux (and yes, we're working on this). Once we have
> > something better, we'll change that to be the defaul
Now that threads are spinned up before machine->init(), clearing
of HF_HALTED_MASK for irqchip in kernel case needs to be moved
to actual vcpu startup.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index f7a217a..50589a7 100644
--- a/qemu/qemu-
Blue Swirl wrote:
>
> I fixed the bug, now pcnet works. Performance is improved by a few
> percent. The problem was that the vector was not freed. Maybe dynamic
> allocation is a bit fragile. In this case, the length of the vector is
> known, so it could be allocated once at init time. But would th
On 4/16/08, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> Blue Swirl wrote:
>
> > On 4/16/08, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> >
> >
> > > This patch introduces a DMA API and plumbs support through the DMA
> layer. We
> > > use a mostly opaque structure, IOVector to represent a scatter
Blue Swirl wrote:
> On 4/16/08, Anthony Liguori <[EMAIL PROTECTED]> wrote:
>
>> This patch introduces a DMA API and plumbs support through the DMA layer. We
>> use a mostly opaque structure, IOVector to represent a scatter/gather list
>> of
>> physical memory. Associated with each IOVector
On 4/16/08, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> This patch introduces a DMA API and plumbs support through the DMA layer. We
> use a mostly opaque structure, IOVector to represent a scatter/gather list of
> physical memory. Associated with each IOVector is a read/write function and
>
Marcelo Tosatti wrote:
> Make sure that all threads are paused in userspace before saving machine
> state.
>
>
Applied, thanks.
--
Any sufficiently difficult bug is indistinguishable from a feature.
-
This SF.net email
Make sure that all threads are paused in userspace before saving machine
state.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
--- kvm-userspace.io/qemu/qemu-kvm.c
+++ kvm-userspace.io/qemu/qemu-kvm.c
@@ -244,7 +244,7 @@ static int all_threads_paused(void)
int i;
for (i = 0; i <
>> KVM supports more than 2GB of memory for x86_64 hosts. The following
>> patch
>> fixes a number of type related issues where int's were being used
>> when they
>> shouldn't have been. It also introduces CMOS support so the BIOS can
>> build
>> the appropriate e820 tables.
>
> Is this alread
On Mon, Feb 04, 2008 at 09:11:01AM -0600, Anthony Liguori wrote:
> KVM supports more than 2GB of memory for x86_64 hosts. The following patch
> fixes a number of type related issues where int's were being used when they
> shouldn't have been. It also introduces CMOS support so the BIOS can build
> +/* Return a new IOVector that's a subset of the passed in IOVector. It
> should + * be freed with qemu_free when you are done with it. */
> +IOVector *iovector_trim(const IOVector *iov, size_t offset, size_t size);
Using qemu_free directly seems a bad idea. I guess we're likely to want to
swi
On 07/04/2008, Paul Brook <[EMAIL PROTECTED]> wrote:
> > As a note, the DMA controllers in the ARM system-on-chip's can
> > byte-swap, do 90deg rotation of 2D arrays, transparency (probably
> > intened for image blitting, but still available on any kind of
> > transfers), etc., and most importan
> As a note, the DMA controllers in the ARM system-on-chip's can
> byte-swap, do 90deg rotation of 2D arrays, transparency (probably
> intened for image blitting, but still available on any kind of
> transfers), etc., and most importantly issue interrupts on reaching
> different points of a transfe
andrzej zaborowski wrote:
> On 06/04/2008, Anthony Liguori <[EMAIL PROTECTED]> wrote:
>
>> Blue Swirl wrote:
>>
>>> To support Sparc IOMMU and DMA controller
>>> I need a way to call a series of different translation functions
>>> depending on the bus where we are. For the byte swapping ca
On 06/04/2008, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> Blue Swirl wrote:
> > To support Sparc IOMMU and DMA controller
> > I need a way to call a series of different translation functions
> > depending on the bus where we are. For the byte swapping case the
> > memcpy functions must be dynami
Blue Swirl wrote:
> On 4/5/08, Anthony Liguori <[EMAIL PROTECTED]> wrote:
>
>> This patch introduces a PCI DMA API and some generic code to support other
>> DMA
>> APIs. It introduces a IOVector type that contains physical address/length
>> pairs. These vectors can be translated by the PCI
On 4/5/08, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> This patch introduces a PCI DMA API and some generic code to support other DMA
> APIs. It introduces a IOVector type that contains physical address/length
> pairs. These vectors can be translated by the PCI layer and passed either to
> ge
Dor Laor wrote:
>
>> +static uint32_t vring_desc_len(VirtQueue *vq, unsigned int i)
>> +{
>
> Below there were place you did use offsetof(vq->vring.desc[i], len) so
> we better be consistent + its nicer
>
>> +return ldl_phys(vq->vring.desc + i * sizeof(VRingDesc) +
>> +offse
Marcelo Tosatti wrote:
> kvm_arch_load_regs() might load APIC base and APIC TPR from the
> uninitialized userspace APIC emulation.
>
> This happened when running X11 on SMP guest in my case, disabling the
> APIC for vcpu3:
>
> vcpu not ready for apic_round_robin
> vcpu not ready for apic_round_robi
* Marcelo Tosatti <[EMAIL PROTECTED]> [2008-04-03 18:22]:
>
> kvm_arch_load_regs() might load APIC base and APIC TPR from the
> uninitialized userspace APIC emulation.
>
> This happened when running X11 on SMP guest in my case, disabling the
> APIC for vcpu3:
>
> vcpu not ready for apic_round_ro
kvm_arch_load_regs() might load APIC base and APIC TPR from the
uninitialized userspace APIC emulation.
This happened when running X11 on SMP guest in my case, disabling the
APIC for vcpu3:
vcpu not ready for apic_round_robin
vcpu not ready for apic_round_robin
vcpu not ready for apic_round_robi
Dor Laor wrote:
> On Sat, 2008-03-29 at 16:55 -0500, Anthony Liguori wrote:
>
>> This patch introduces virtio support over PCI. virtio is a generic virtual
>> IO
>> framework for Linux first introduced in 2.6.23. Since 2.6.25, virtio has
>> supported a PCI transport which this patch implement
On Sat, 2008-03-29 at 16:55 -0500, Anthony Liguori wrote:
> This patch introduces virtio support over PCI. virtio is a generic virtual IO
> framework for Linux first introduced in 2.6.23. Since 2.6.25, virtio has
> supported a PCI transport which this patch implements.
>
> Since the last time t
1 - 100 of 467 matches
Mail list logo
