Re: [Qemu-devel] [PATCH v3 0/4]: Convert pci_info() to QObject
Luiz Capitulino writes: > Hi, > > This new version fixes the printing of PCI bridge information, > as I was able to test it after some help from Blue Swirl. > > Only the printing of PCI bridge attached devices remains > untested, but according to Blue Swirl attaching devices to it > is broken so I don't think it matters much. Good enough for me.
Re: [Qemu-devel] [PATCH 3/4] Add -defaults option to allow default devices to be overridden
Anthony Liguori writes:
> This option can be used to toggle whether each default device is enabled or
> disabled. For character devices, the default backend can also be overridden.
>
> For devices, we'll have to take a different approach to changing the defaults
> which will be covered in the next patch.
>
> N.B. I took special care with -nographic. Now -nographic pretty clearly acts
> as a mechanism to override the default backend devices.
>
> Signed-off-by: Anthony Liguori
> ---
> qemu-config.c | 45 +
> qemu-config.h |1 +
> qemu-options.hx |7 +
> vl.c| 75
> +--
> 4 files changed, 109 insertions(+), 19 deletions(-)
>
> diff --git a/qemu-config.c b/qemu-config.c
> index c3203c8..82ca399 100644
> --- a/qemu-config.c
> +++ b/qemu-config.c
> @@ -242,6 +242,50 @@ QemuOptsList qemu_mon_opts = {
> },
> };
>
> +QemuOptsList qemu_default_opts = {
> +.name = "default",
> +.head = QTAILQ_HEAD_INITIALIZER(qemu_default_opts.head),
> +.desc = {
> +{
> +.name = "serial",
> +.type = QEMU_OPT_STRING,
> +},
[...]
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 57f453d..e81ecb5 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -1919,6 +1919,13 @@ STEXI
> Don't create default devices.
> ETEXI
>
> +DEF("default", HAS_ARG, QEMU_OPTION_default, \
> +"-default argspecify default devices\n")
Isn't this too terse?
> +STEXI
> +...@item -defaults
> +Override builtin default devices
> +ETEXI
This *is* too terse :)
Oh, and it's -default (sans 's'). Same typo in subject.
While we're talking about naming: isn't -default a bit too generic a
name for something that manipulates devices? Not sure we care, as
-nodefaults is much worse, already.
[...]
Re: [Qemu-devel] [RFC 00/11]: QMP feature negotiation support
A few quick questions before I dive into the patches...
Luiz Capitulino writes:
> Feature negotiation allows clients to enable QMP capabilities they are
> interested in using. This allows QMP to envolve without breaking old clients.
>
> A capability is a new QMP feature and/or protocol change which is not part of
> the core protocol as defined in the QMP spec.
>
> Feature negotiation is implemented by defining a set of rules and adding
> mode-oriented support.
>
> The set of rules are:
>
> o All QMP capabilities are disabled by default
> o All QMP capabilities must be advertised in the capabilities array
> o Commands to enable/disable capabilities must be provided
>
> NOTE: Asynchronous messages are now considered a capability.
>
> Mode-oriented support adds the following to QMP:
>
> o Two modes: handshake and operational
> o By default all QMP Monitors start in handshake mode
"By default"? Is there a way to start a QMP monitor in another mode?
> o In handshake mode only commands to query/enable/disable QMP capabilities are
> allowed (there are few exceptions)
Note to self: check out the exception, and why we might want them.
> o Clients can switch to the operational mode at any time
Can they switch back? I hope not.
> o In Operational mode most commands are allowed and QMP capabilities changes
> made in handshake mode take effect
>
> Also note that each QMP Monitor has its own mode state and set of
> capabilities,
> this means that if QEMU is started with N QMP Monitors protocol setup done in
> one of them doesn't affect the others.
>
> Session example:
>
> """
> {"QMP": {"capabilities": ["async messages"]}}
>
> { "execute": "query-qmp-mode" }
> {"return": {"mode": "handshake"}}
Why would clients want to query the mode?
> { "execute": "change", "arguments": { "device": "vnc", "target": "password",
> "arg": "1234" } }
> {"error": {"class": "QMPInvalidModeCommad", "desc": "The issued command is
> invalid in this mode", "data": {}}}
I'd treat this like a completely unknown command.
> { "execute": "async_msg_enable", "arguments": { "name": "STOP" } }
> {"return": {}}
>
> { "execute": "qmp_switch_mode", "arguments": { "mode": "operational" } }
> {"return": {}}
Do we envisage mode transitions other than handshake -> operational?
> { "execute": "query-qmp-mode" }
> {"return": {"mode": "operational"}}
>
> { "execute": "change", "arguments": { "device": "vnc", "target": "password",
> "arg": "1234" } }
> {"return": {}}
> """
>
> TODO:
>
> - Update the spec
> - Test more and fix some known issues
> - Improve the changelog a bit
[Qemu-devel] Re: [PATCH 2/4] Load global config files by default
On 01/21/10 19:48, Anthony Liguori wrote: The ordering is a little troubling. Command line options are parsed before loading the default configs which means that the command line configs will be loaded before the default config. The effect is that the default config will override -readconfig directives. > It's unclear the best way to handle this. Maybe we need two passes over the command line options? -confdir and -nodefconfig switches would be handled in the first pass, then read the global config files (unless disabled), then the second pass. I think we could also make the default device handling less messy that way by checking -nographic and -nodefaults in the first pass too. Having the machine type (-M) read in the first pass could allow some cleanups too. cheers, Gerd
[Qemu-devel] Re: [PATCH 4/4] Allow default network type to be overridden
On 01/21/10 19:48, Anthony Liguori wrote: Introduce a default option to the network device which specifies that this is a default network device. This approach should generalize to any other device. The meaning of a default device is as follows: a default device is added to a machine IIF defaults aren't disable (via -default or -nodefaults) and a non-default device of this type hasn't been added. I don't like the idea to have two different mechanisms for configuring defaults ([default] section + default = "on"). I'd suggest to pick one and apply it everythere. cheers, Gerd
Re: [Qemu-devel] [PATCH] loader: don't call realloc(O) when no symbols are present
Jamie Lokier writes: > Markus Armbruster wrote: >> I didn't claim there's *no* difference between C89 and C99. In fact, >> the Rationale nicely documents the change: >> >> [snipped] >> Also, implementations that support an >> actual allocation when the size is zero do not necessarily return a >> null pointer for this case. C89 appeared to require a null return >> value, and the Committee felt that this was too restrictive. >> >> So C99 permits realloc(p, 0) to return a non-null value. Regardless, it >> still *requires* it to free(p). > > Nobody disagrees that it does free(p). Apparently malc does. > The question is whether it may _follow_ the free(p) with malloc(0) and > return that, in which case the returned pointer must eventually be > passed to a subsequent free() to avoid leaks, or if it only doess > free(p) and a non-null result must be ignored. > > For either meaning of non-null result, there are valid C89 programs which > will break, either leaking or calling free() on an invalid address. > >> I just want to correct the misinformation on the standard being >> spread on this list. > > I can't tell from your writing which misinformation you mean. I mean the claim that realloc(p, 0) does not always free(p). > The only thing in question is the (new in C99) possibility of non-null > result and what to do with one (that it does free(p) is not in doubt), > and I'm afriad the sections you quoted firmly support the non-null > result change, and perpetuate the ambiguity of it's meaning. > > In any case, there is no doubt, from the possibiliy of non-null result > alone (which is clear), that is already enough to make some valid C89 > code misbehave. > > The ambiguity of a non-null result (i.e. whether it is equivalent to > malloc(0) and the caller must free it later, or it is something the > caller must ignore because the realloc(p,0) call is equivalent to > free(p) only) is what makes it seem unsafe to call realloc(p,0) at all. > > I don't want to argue and I really appreciate your clarification if > you know something. If there is misinformation, it would be good to > correct it, in which case I don't think you have succeeded. > > Unfortunately I can't tell from your mail what you think the meaning > of a non-null result is. There is really nothing special about a non-null value returned by realloc(p, 0). Quoting C99 7.20.3.4: The realloc function returns a pointer to the new object (which may have the same value as a pointer to the old object), or a null pointer [...] So this is really the same deal as with malloc(): * If you get a non-null value, you should pass it to free() to avoid memory leaks (actually, you may pass any value you get to free, since free() does nothing for null arguments). * Checking for failure is tricky, because size argument zero may get you a null value. There is no "ambiguity of a non-null result". You are right on C99 breaking programs that assumed realloc(p, 0) *always* returned null. Quoting the C99 Rationale (emphasis mine): Also, implementations that support an actual allocation when the size is zero do not necessarily return a null pointer for this case. C89 *appeared* to require a null return value, and the Committee felt that this was too restrictive. And this is where C89 7.10.3.4 appears to require it, but in fact doesn't: Description [...] If ptr is a null pointer, the realloc function behaves like the malloc function for the specified size. Otherwise, if ptr does not match a pointer earlier returned by the calloc, malloc, or realloc function, or if the space has been deallocated by a call to the free or realloc function, the behavior is undefined. If the space cannot be allocated, the object pointed to by ptr is unchanged. If size is zero and ptr is not a null pointer, the object it points to is freed. The last sentence specifies only that the old object is freed. It doesn't specify return of a null value. The return value is covered by the *next* section: Returns The realloc function returns either a null pointer or a a pointer to the possibly moved allocated space. For C99, the committee made the fact that realloc(p, 0) need not return null explicit. Unfortunately, they messed up the wording, which has led a few people to believe the spec for realloc() changed incompatibly in C99. It did not. Anything still unclear? The practical question is of course whether realloc(p, 0) can be used safely in portable programs. It can, in the same way it's always been used: * If it yields a non-null value, you pass it to free() * If it yields a null value, this means "out of memory" only if you asked for a non-zero size. Note that such a portable program doesn't need to know how the implementation defines behavior for zero arguments.
Re: [Qemu-devel] [PATCH 01/14] arm host: Fix compiler warning
On Wed, Jan 20, 2010 at 6:43 PM, Stefan Weil wrote:
> Compilation for arm (native or cross) results in this
> warning:
>
> fpu/softfloat-native.c: In function ‘float64_round_to_int’:
> fpu/softfloat-native.c:387: error: control reaches end of non-void function
>
> float64_round_to_int uses special assembler code for arm
> and has no explicit return value.
>
> As there is no obvious reason why arm should need special
> code, all fpu related conditionals were removed.
> The remaining code is standard (C99) and compiles for arm,
> too.
>
> Signed-off-by: Stefan Weil
Acked-by: Laurent Desnogues
Laurent
> ---
> fpu/softfloat-native.c | 20
> fpu/softfloat-native.h | 7 ---
> 2 files changed, 0 insertions(+), 27 deletions(-)
>
> diff --git a/fpu/softfloat-native.c b/fpu/softfloat-native.c
> index 8d64f4e..049c830 100644
> --- a/fpu/softfloat-native.c
> +++ b/fpu/softfloat-native.c
> @@ -12,8 +12,6 @@ void set_float_rounding_mode(int val STATUS_PARAM)
> #if (defined(CONFIG_BSD) && !defined(__APPLE__) && !defined(__GLIBC__)) || \
> (defined(CONFIG_SOLARIS) && CONFIG_SOLARIS_VERSION < 10)
> fpsetround(val);
> -#elif defined(__arm__)
> - /* nothing to do */
> #else
> fesetround(val);
> #endif
> @@ -365,25 +363,7 @@ float64 float64_trunc_to_int( float64 a STATUS_PARAM )
>
> float64 float64_round_to_int( float64 a STATUS_PARAM )
> {
> -#if defined(__arm__)
> - switch(STATUS(float_rounding_mode)) {
> - default:
> - case float_round_nearest_even:
> - asm("rndd %0, %1" : "=f" (a) : "f"(a));
> - break;
> - case float_round_down:
> - asm("rnddm %0, %1" : "=f" (a) : "f"(a));
> - break;
> - case float_round_up:
> - asm("rnddp %0, %1" : "=f" (a) : "f"(a));
> - break;
> - case float_round_to_zero:
> - asm("rnddz %0, %1" : "=f" (a) : "f"(a));
> - break;
> - }
> -#else
> return rint(a);
> -#endif
> }
>
> float64 float64_rem( float64 a, float64 b STATUS_PARAM)
> diff --git a/fpu/softfloat-native.h b/fpu/softfloat-native.h
> index fe737b3..6da0bcb 100644
> --- a/fpu/softfloat-native.h
> +++ b/fpu/softfloat-native.h
> @@ -126,13 +126,6 @@ enum {
> float_round_up = FP_RP,
> float_round_to_zero = FP_RZ
> };
> -#elif defined(__arm__)
> -enum {
> - float_round_nearest_even = 0,
> - float_round_down = 1,
> - float_round_up = 2,
> - float_round_to_zero = 3
> -};
> #else
> enum {
> float_round_nearest_even = FE_TONEAREST,
> --
> 1.6.5
>
>
>
>
Re: [Qemu-devel] [RFC 00/11]: QMP feature negotiation support
On Fri, 22 Jan 2010 11:21:22 +0100
Markus Armbruster wrote:
> A few quick questions before I dive into the patches...
>
> Luiz Capitulino writes:
>
> > Feature negotiation allows clients to enable QMP capabilities they are
> > interested in using. This allows QMP to envolve without breaking old
> > clients.
> >
> > A capability is a new QMP feature and/or protocol change which is not part
> > of
> > the core protocol as defined in the QMP spec.
> >
> > Feature negotiation is implemented by defining a set of rules and adding
> > mode-oriented support.
> >
> > The set of rules are:
> >
> > o All QMP capabilities are disabled by default
> > o All QMP capabilities must be advertised in the capabilities array
> > o Commands to enable/disable capabilities must be provided
> >
> > NOTE: Asynchronous messages are now considered a capability.
> >
> > Mode-oriented support adds the following to QMP:
> >
> > o Two modes: handshake and operational
> > o By default all QMP Monitors start in handshake mode
>
> "By default"? Is there a way to start a QMP monitor in another mode?
No, you think it's worth or is it just about the English?
> > o In handshake mode only commands to query/enable/disable QMP capabilities
> > are
> > allowed (there are few exceptions)
>
> Note to self: check out the exception, and why we might want them.
The following handlers are handshake-only:
- qmp_switch_mode
- async_msg_enable
- async_msg_disable
The following handlers are allowed to run on both modes:
- query-version
- query-qmp-mode
- query-commands
Also, all the self-description commands (query-async-msg,
query-errors etc) would be allowed on both modes.
So, the only handler which is not completely related to feature
negotiation is query-version. This is only a guess, but I think
it might be worth to let clients learn the QEMU version they are
talking to before setting protocol features.
> > o Clients can switch to the operational mode at any time
>
> Can they switch back? I hope not.
No, they can't. The only transition allowed is handshake -> operational.
> > o In Operational mode most commands are allowed and QMP capabilities changes
> > made in handshake mode take effect
> >
> > Also note that each QMP Monitor has its own mode state and set of
> > capabilities,
> > this means that if QEMU is started with N QMP Monitors protocol setup done
> > in
> > one of them doesn't affect the others.
> >
> > Session example:
> >
> > """
> > {"QMP": {"capabilities": ["async messages"]}}
> >
> > { "execute": "query-qmp-mode" }
> > {"return": {"mode": "handshake"}}
>
> Why would clients want to query the mode?
It's more useful for testing purposes.
> > { "execute": "change", "arguments": { "device": "vnc", "target":
> > "password", "arg": "1234" } }
> > {"error": {"class": "QMPInvalidModeCommad", "desc": "The issued command is
> > invalid in this mode", "data": {}}}
>
> I'd treat this like a completely unknown command.
Really? This would simplify things a bit.
> > { "execute": "async_msg_enable", "arguments": { "name": "STOP" } }
> > {"return": {}}
> >
> > { "execute": "qmp_switch_mode", "arguments": { "mode": "operational" } }
> > {"return": {}}
>
> Do we envisage mode transitions other than handshake -> operational?
Today we don't, but this is about forward compatibility support right? :)
So, IMO it makes sense to have a more general command instead of
qmp_switch_operational.
[Qemu-devel] Re: [PATCH 1/4] Support --confdir in configure to specify path to configuration files
On 01/21/2010 07:48 PM, Anthony Liguori wrote: --confdir can be used to override the default to an absolute path. The expectation is that when installed to /usr, --confdir=/etc/qemu will be used. Why not --sysconfdir? There are already several differences between Autoconf options and QEMU configure options, however unlike the others this one would be used by basically all distros. Paolo
Re: [Qemu-devel] [PATCH] loader: don't call realloc(O) when no symbols are present
malc writes: > On Thu, 21 Jan 2010, Markus Armbruster wrote: > >> malc writes: >> >> > On Thu, 21 Jan 2010, Markus Armbruster wrote: > > [..snip..] > >> >> No, this is a misinterpretation of the C99 standard, made possible by >> >> its poor wording. The C99 Rationale is perfectly clear, though: >> > >> > You have to show the flaw in Hallvard B Furuseth's analysis to claim >> > that it's a misinterpretation. And unlike the standard rationale is >> > non normative. >> > >> > [..snip..] >> >> I did. If that doesn't convince you, I'll gladly wait for the Technical >> Corrigendum that'll put this rather absurd misreading to rest. > > If you did, then, i guess, i've missed it, here's the whole analysis, > please point what and where is wrong: > > [quote: > http://groups.google.com/group/comp.std.c/browse_thread/thread/4e9af8847613d71f/6f75ad22e0768a0b?q=realloc++group:comp.std.c#6f75ad22e0768a0b] > > C90 said realloc(non-null, 0) did free(). C99 inverted that, saying it > does not: > > The only place where 7.20.3.4 (The realloc function) mentions that > realloc may free the old object, is in the case where it returns another > object. 7.20.3.4 starts with the simple, unconditional statement: The realloc function deallocates the old object pointed to by ptr and returns a pointer to a new object that has the size specified by size. The only place where it limits this clause is here: If memory for the new object cannot be allocated, the old object is not deallocated and its value is unchanged. Therefore, saying that realloc() frees the old object only when "it returns another object" is imprecise. What the standard *actually* says is realloc() frees unless "the new object cannot be allocated". The question is whether returning null for a zero-sized allocation is to be considered "the new object cannot be allocated". The claim that realloc(p, 0) may not free(p) relies on the answer to that question being "yes". However, the Rationale maintains that the answer is "no". Which is consistent with the previous iteration of the standard, common usage predating the standard, and thus with the standard's mission to avoid "quiet changes". > 7.20.3 (Memory management functions) says zero-sized allocation > returns NULL, but 7.20.3.4 overrides that. > > Could we have the original behavior back, please? I've seen people say > the current definition is unintentional. And it conflicts with the C99 > Rationale: > >7.20.3.4 The realloc function > >(...) If the first argument is not null, and the second argument is >0, then the call frees the memory pointed to by the first argument, > > though that goes on with > >and a null argument may be returned; C99 is consistent with the >policy of not allowing zero-sized objects. > > Is that supposed to mean no new object is returned but the return value > is indeterminate, or does it mean that it might free the old object and > return an inaccessible new object like malloc(0)? It means it must free the old object and may return either null or an inaccessible new object, just like malloc(0). The "policy of not allowing zero-sized objects" refers back to 7.20.3: Some implementations have returned non-null values for allocation requests of zero bytes. Although this strategy has the theoretical advantage of distinguishing between "nothing" and "zero" (an unallocated pointer vs. a pointer to zero-length space), it has the more compelling theoretical disadvantage of requiring the concept of a zero-length object. Since such objects cannot be declared, the only way they could come into existence would be through such allocation requests. The C89 Committee decided not to accept the idea of zero-length objects. The allocation functions may therefore return a null pointer for an allocation request of zero bytes. Note that this treatment does not preclude the paradigm outlined above. > Repeating from old realloc(non-null, 0) discussions: > > In the latter case a program which sees a NULL return from > realloc(non-null, 0) cannot know if the old object was freed or not - > i.e. it cannot know if the NULL was a failure return (from allocating > the new object) or a success return (after freeing the old object). > > Which is exactly the situation for a portable program which sees such a > NULL return today - it cannot know if it was a C99 failure return or a > C90 success return. Even if the language is C99, the library might be > C90. > > [end quote] If your reading of the standard leads to conclusions like "breaks most existing programs in an unfixable way", in absence of any evidence of such breakage in practice, then it's maybe time to double-check it against the Rationale. If C99 made the sky fall, we'd be done being crushed by now :)
Re: [Qemu-devel] [PATCH] loader: don't call realloc(O) when no symbols are present
malc writes: > On Thu, 21 Jan 2010, Jamie Lokier wrote: > >> Markus Armbruster wrote: >> > malc writes: >> > >> > > On Tue, 29 Dec 2009, Jamie Lokier wrote: >> > > >> > >> malc wrote: >> > >> > On Mon, 28 Dec 2009, Jamie Lokier wrote: >> > >> > >> > >> > > Aurelien Jarno wrote: >> > >> > > > This fixes the loading of a stripped kernel with zero malloc >> > >> > > > disabled. >> > >> > > >> > >> > > *Raises an eyebrow* >> > >> > > >> > >> > > Even though there's different perspectives over whether >> > >> > > qemu_malloc(0) >> > >> > > should be allowed, inherited from ambiguity over malloc(0), >> > >> > > realloc(p,0) has always had a standard, well-defined meaning. >> > >> > >> > >> > No. >> > >> > http://groups.google.com/group/comp.std.c/browse_thread/thread/4e9af8847613d71f/6f75ad22e0768a0b?q=realloc++group:comp.std.c#6f75ad22e0768a0b >> > >> >> > >> Wow, thanks for that. It's a real surprise. Looks like C99's own >> > >> rationale is not consistent with itself on the subject, and differs >> > >> from C90 where the "standard, well-defined meaning" I referred to was >> > >> defined. >> > > >> > > Yep. >> > >> > No, this is a misinterpretation of the C99 standard, made possible by >> > its poor wording. The C99 Rationale is perfectly clear, though: >> > >> > 7.20.3.4 The realloc function >> > >> > A null first argument is permissible. If the first argument is not >> > null, and the second argument is 0, then the call frees the memory >> > pointed to by the first argument, and a null argument may be >> > returned; [...] >> >> The rationale above does not match C89 behaviour. It says the call >> frees the memory, but it does not forbid the call from then proceeding >> to do the same as malloc(0) and return a non-NULL pointer. It's quite >> explicit: a null argument *may* be returned. Which means the >> rationale does not require realloc(p,0) to do the same as C89, which >> always frees the memory and doesn't allocate anything. >> >> > This is hardly surprising, because anything else would break working C89 >> > programs, and that would squarely contradict the standard's mission, >> >> Understood. But it doesn't really matter what's intended or what's >> misinterpreted. If there are any significant implementations out >> there based on the "misinterpretation", or even based on the >> rationale, that's enough of a reason to not depend on realloc(p,0). >> > > My sentiment exactly. > > An example: > > Dinkum Unabridged Library was certified by Perennial > (http://peren.com/pages/aboutus_set.htm) to conform > to ISO/IEC 9899:1999. > > Documentation for realloc: > http://www.dinkumware.com/manuals/?manual=compleat&Search=realloc&page=stdlib.html#realloc > > Hallvard B Furuseth analysis fully applies i believe... Regardless of whether his analysis applies to this implementation's documentation or not: what does this implementation actually do?
[Qemu-devel] [PATCH] block/raw-posix: Abort on pread beyond end of non-growable file
This shouldn't happen under any normal circumstances. However, it looks like
it's possible to achieve this with corrupted images. Without this patch
raw_pread is hanging in an endless loop in such cases.
The patch is not affecting growable files, for which such reads happen in
normal use cases. raw_pread_aligned already handles these cases and won't
return zero in the first place.
Signed-off-by: Kevin Wolf
---
block/raw-posix.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/block/raw-posix.c b/block/raw-posix.c
index 4d79881..6ef1cff 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -403,8 +403,12 @@ static int raw_pread(BlockDriverState *bs, int64_t offset,
size = ALIGNED_BUFFER_SIZE;
ret = raw_pread_aligned(bs, offset, s->aligned_buf, size);
-if (ret < 0)
+if (ret < 0) {
return ret;
+} else if (ret == 0) {
+fprintf(stderr, "raw_pread: read beyond end of file\n");
+abort();
+}
size = ret;
if (size > count)
--
1.6.5.2
Re: [Qemu-devel] [RFC 00/11]: QMP feature negotiation support
Luiz Capitulino writes:
> On Fri, 22 Jan 2010 11:21:22 +0100
> Markus Armbruster wrote:
>
>> A few quick questions before I dive into the patches...
>>
>> Luiz Capitulino writes:
>>
>> > Feature negotiation allows clients to enable QMP capabilities they are
>> > interested in using. This allows QMP to envolve without breaking old
>> > clients.
>> >
>> > A capability is a new QMP feature and/or protocol change which is not
>> > part of
>> > the core protocol as defined in the QMP spec.
>> >
>> > Feature negotiation is implemented by defining a set of rules and adding
>> > mode-oriented support.
>> >
>> > The set of rules are:
>> >
>> > o All QMP capabilities are disabled by default
>> > o All QMP capabilities must be advertised in the capabilities array
>> > o Commands to enable/disable capabilities must be provided
>> >
>> > NOTE: Asynchronous messages are now considered a capability.
>> >
>> > Mode-oriented support adds the following to QMP:
>> >
>> > o Two modes: handshake and operational
>> > o By default all QMP Monitors start in handshake mode
>>
>> "By default"? Is there a way to start a QMP monitor in another mode?
>
> No, you think it's worth or is it just about the English?
Just about the language.
>> > o In handshake mode only commands to query/enable/disable QMP capabilities
>> > are
>> > allowed (there are few exceptions)
>>
>> Note to self: check out the exception, and why we might want them.
>
> The following handlers are handshake-only:
>
> - qmp_switch_mode
> - async_msg_enable
> - async_msg_disable
Two commands per feature? I'd rather have a single "feature NAME
VALUE", where NAME identifies the feature, and VALUE specifies whether
to turn it on or off.
> The following handlers are allowed to run on both modes:
>
> - query-version
> - query-qmp-mode
> - query-commands
>
> Also, all the self-description commands (query-async-msg,
> query-errors etc) would be allowed on both modes.
>
> So, the only handler which is not completely related to feature
> negotiation is query-version. This is only a guess, but I think
> it might be worth to let clients learn the QEMU version they are
> talking to before setting protocol features.
I'd simply announce it in the greeting, just like the features.
But I don't mind supporting selected query- commands in handshake mode,
if that's easy to do.
>> > o Clients can switch to the operational mode at any time
>>
>> Can they switch back? I hope not.
>
> No, they can't. The only transition allowed is handshake -> operational.
>
>> > o In Operational mode most commands are allowed and QMP capabilities
>> > changes
>> > made in handshake mode take effect
>> >
>> > Also note that each QMP Monitor has its own mode state and set of
>> > capabilities,
>> > this means that if QEMU is started with N QMP Monitors protocol setup done
>> > in
>> > one of them doesn't affect the others.
>> >
>> > Session example:
>> >
>> > """
>> > {"QMP": {"capabilities": ["async messages"]}}
>> >
>> > { "execute": "query-qmp-mode" }
>> > {"return": {"mode": "handshake"}}
>>
>> Why would clients want to query the mode?
>
> It's more useful for testing purposes.
Just try a command that works only in one of the modes ;)
>> > { "execute": "change", "arguments": { "device": "vnc", "target":
>> > "password", "arg": "1234" } }
>> > {"error": {"class": "QMPInvalidModeCommad", "desc": "The issued command is
>> > invalid in this mode", "data": {}}}
>>
>> I'd treat this like a completely unknown command.
>
> Really? This would simplify things a bit.
Simple is good.
>> > { "execute": "async_msg_enable", "arguments": { "name": "STOP" } }
>> > {"return": {}}
>> >
>> > { "execute": "qmp_switch_mode", "arguments": { "mode": "operational" } }
>> > {"return": {}}
>>
>> Do we envisage mode transitions other than handshake -> operational?
>
> Today we don't, but this is about forward compatibility support right? :)
>
> So, IMO it makes sense to have a more general command instead of
> qmp_switch_operational.
I'd say transitioning from initial feature negotiation to normal
operations is a special case, so generality is not needed here. I'm
fine with you providing it anyway.
[Qemu-devel] Re: [PATCH 1/4] Support --confdir in configure to specify path to configuration files
On 01/22/2010 06:43 AM, Paolo Bonzini wrote: On 01/21/2010 07:48 PM, Anthony Liguori wrote: --confdir can be used to override the default to an absolute path. The expectation is that when installed to /usr, --confdir=/etc/qemu will be used. Why not --sysconfdir? There are already several differences between Autoconf options and QEMU configure options, however unlike the others this one would be used by basically all distros. Wasn't 100% sure on the proper naming. sysconfdir works for me. Regards, Anthony Liguori Paolo
[Qemu-devel] Re: [PATCH 4/4] Allow default network type to be overridden
On 01/22/2010 05:00 AM, Gerd Hoffmann wrote: On 01/21/10 19:48, Anthony Liguori wrote: Introduce a default option to the network device which specifies that this is a default network device. This approach should generalize to any other device. The meaning of a default device is as follows: a default device is added to a machine IIF defaults aren't disable (via -default or -nodefaults) and a non-default device of this type hasn't been added. I don't like the idea to have two different mechanisms for configuring defaults ([default] section + default = "on"). I'd suggest to pick one and apply it everythere. I agree that it's awkward. Need to think a bit about it. Regards, Anthony Liguori cheers, Gerd
Re: [Qemu-devel] [PATCH 3/4] Add -defaults option to allow default devices to be overridden
On 01/22/2010 04:15 AM, Markus Armbruster wrote:
Anthony Liguori writes:
This option can be used to toggle whether each default device is enabled or
disabled. For character devices, the default backend can also be overridden.
For devices, we'll have to take a different approach to changing the defaults
which will be covered in the next patch.
N.B. I took special care with -nographic. Now -nographic pretty clearly acts
as a mechanism to override the default backend devices.
Signed-off-by: Anthony Liguori
---
qemu-config.c | 45 +
qemu-config.h |1 +
qemu-options.hx |7 +
vl.c| 75 +--
4 files changed, 109 insertions(+), 19 deletions(-)
diff --git a/qemu-config.c b/qemu-config.c
index c3203c8..82ca399 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -242,6 +242,50 @@ QemuOptsList qemu_mon_opts = {
},
};
+QemuOptsList qemu_default_opts = {
+.name = "default",
+.head = QTAILQ_HEAD_INITIALIZER(qemu_default_opts.head),
+.desc = {
+{
+.name = "serial",
+.type = QEMU_OPT_STRING,
+},
[...]
diff --git a/qemu-options.hx b/qemu-options.hx
index 57f453d..e81ecb5 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1919,6 +1919,13 @@ STEXI
Don't create default devices.
ETEXI
+DEF("default", HAS_ARG, QEMU_OPTION_default, \
+"-default argspecify default devices\n")
Isn't this too terse?
Yes. Thanks for pointing that out.
+STEXI
+...@item -defaults
+Override builtin default devices
+ETEXI
This *is* too terse :)
Oh, and it's -default (sans 's'). Same typo in subject.
While we're talking about naming: isn't -default a bit too generic a
name for something that manipulates devices? Not sure we care, as
-nodefaults is much worse, already.
Absolutely. I'm going to split out the config loading bits because they
should be easy to commit. How to best handle defaults could use some
more thought. I think this is a key bit of functionality to get right
though because it solves a whole class of problems relating to upstream
policy vs. downstream policy.
I very much like the idea of having a qdev property 'default' to signify
that this is a default device. It means we could easily allow a user to
universally enable usb devices, etc without baking a default_usb concept
into qemu. Ideally, we could eliminate the whole default mess we have
today by doing this, provided that we can implement the right semantics.
Today, those semantics are, if we specify any device of the same
"class", do not load default devices of that class. It's unclear how to
specify the concept of a "class" though. I know Gerd brought this up
ages ago and both Paul and I were very opposed to it but I certainly
appreciate the fact that it would simplify default device handling.
It's definitely clear that each device needs to be able to be part of
multiple default-class's. We could potentially introduce a qdev
property and label every device with a class array but that's a lot of
ugliness just to support defaults. I still would prefer that there was
a more discoverable way to determine the class of a device as opposed to
explicitly labelling it.
If we need to do class tagging, I guess it's not the end of the world...
Regards,
Anthony Liguori
[...]
Re: [Qemu-devel] [PATCH] Porting TCG to alpha platform
Hi, Richard.
I almost re-write the whole code under your help and now it seems somehow
elegant. Unfortunately, it still can't run MS windows, I wonder whether there
are some other special places in QEMU to be modifed for alpha case, beside the
3 files (cpu-all.h/tcg-target.c/tcg-target.h) I write or modified.
Is there any good method to find the bug except "guess and try"? And it seems
that few people is interested in porting QEMU/TCG to alpha platform, why? just
because alpha machine is disappearing? And may the patch in current stage be
accepted by QEMU, i just want to attract more eye-balls and to get things done.
Anyhow, I'll continue to work on it and any help from you will be appreciated.
I append the newest patch in attachment, please take a look if it doesn't waste
too much your time.
Thanks.
Dong Weiyu
___
好玩贺卡等你发，邮箱贺卡全新上线！
http://card.mail.cn.yahoo.com/From d51491a60ccf9ab91eb963ba07be2e590afda71d Mon Sep 17 00:00:00 2001
From: Dong Weiyu
Date: Fri, 22 Jan 2010 23:10:43 +0800
Subject: [PATCH] Porting TCG to alpha platform
---
cpu-all.h |2 +-
tcg/alpha/tcg-target.c | 1081
tcg/alpha/tcg-target.h | 68 +++
3 files changed, 1150 insertions(+), 1 deletions(-)
create mode 100644 tcg/alpha/tcg-target.c
create mode 100644 tcg/alpha/tcg-target.h
diff --git a/cpu-all.h b/cpu-all.h
index e0c3efd..bdf6fb2 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -22,7 +22,7 @@
#include "qemu-common.h"
-#if defined(__arm__) || defined(__sparc__) || defined(__mips__) || defined(__hppa__)
+#if defined(__arm__) || defined(__sparc__) || defined(__mips__) || defined(__hppa__) || defined(__alpha__)
#define WORDS_ALIGNED
#endif
diff --git a/tcg/alpha/tcg-target.c b/tcg/alpha/tcg-target.c
new file mode 100644
index 000..977c9b1
--- /dev/null
+++ b/tcg/alpha/tcg-target.c
@@ -0,0 +1,1081 @@
+/*
+ * Tiny Code Generator for QEMU on ALPHA platform
+*/
+
+#ifndef NDEBUG
+static const char * const tcg_target_reg_names[TCG_TARGET_NB_REGS] = {
+"$0", "$1", "$2", "$3", "$4", "$5", "$6", "$7",
+"$8", "$9", "$10", "$11", "$12", "$13", "$14", "$15",
+"$16", "$17", "$18", "$19", "$20", "$21", "$22", "$23",
+"$24", "$25", "$26", "$27", "$28", "$29", "$30", "$31",
+};
+#endif
+
+/*
+ * $26, $27, $29, $30, $31 are special, reserved,
+ * $28 is reserved as temporary register.
+*/
+static const int tcg_target_reg_alloc_order[] = {
+TCG_REG_9, TCG_REG_10, TCG_REG_11, TCG_REG_12, TCG_REG_13, TCG_REG_14,
+TCG_REG_1, TCG_REG_2, TCG_REG_3, TCG_REG_4, TCG_REG_5, TCG_REG_6,
+TCG_REG_7, TCG_REG_8, TCG_REG_22, TCG_REG_23, TCG_REG_24, TCG_REG_25,
+TCG_REG_16, TCG_REG_17, TCG_REG_18, TCG_REG_19, TCG_REG_20, TCG_REG_21
+};
+
+/*
+ * according to alpha calling convention, these 6 registers are used for
+ * function parameter passing. if function has more than 6 parameters, remained
+ * ones are stored on stack.
+*/
+static const int tcg_target_call_iarg_regs[6] = {
+TCG_REG_16, TCG_REG_17, TCG_REG_18, TCG_REG_19, TCG_REG_20, TCG_REG_21
+};
+
+/*
+ * according to alpha calling convention, $0 is used for returning function result.
+*/
+static const int tcg_target_call_oarg_regs[1] = { TCG_REG_0 };
+
+/*
+ * save the address of TB's epilogue.
+*/
+static uint8_t *tb_ret_addr;
+
+#define INSN_OP(x) (((x) & 0x3f) << 26)
+#define INSN_FUNC1(x) (((x) & 0x3) << 14)
+#define INSN_FUNC2(x) (((x) & 0x7f) << 5)
+#define INSN_RA(x) (((x) & 0x1f) << 21)
+#define INSN_RB(x) (((x) & 0x1f) << 16)
+#define INSN_RC(x) ((x) & 0x1f)
+#define INSN_LIT(x)(((x) & 0xff) << 13)
+#define INSN_DISP16(x) ((x) & 0x)
+#define INSN_DISP21(x) ((x) & 0x1f)
+#define INSN_RSVED(x) ((x) & 0x3fff)
+
+#define INSN_JMP (INSN_OP(0x1a) | INSN_FUNC1(0))
+#define INSN_CALL (INSN_OP(0x1a) | INSN_FUNC1(1))
+#define INSN_RET (INSN_OP(0x1a) | INSN_FUNC1(2))
+#define INSN_BRINSN_OP(0x30)
+#define INSN_BEQ INSN_OP(0x39)
+#define INSN_BNE INSN_OP(0x3d)
+#define INSN_BLBC INSN_OP(0x38)
+#define INSN_BLBS INSN_OP(0x3c)
+#define INSN_ADDL (INSN_OP(0x10) | INSN_FUNC2(0))
+#define INSN_SUBL (INSN_OP(0x10) | INSN_FUNC2(0x9))
+#define INSN_ADDQ (INSN_OP(0x10) | INSN_FUNC2(0x20))
+#define INSN_SUBQ (INSN_OP(0x10) | INSN_FUNC2(0x29))
+#define INSN_CMPEQ (INSN_OP(0x10) | INSN_FUNC2(0x2d))
+#define INSN_CMPLT (INSN_OP(0x10) | INSN_FUNC2(0x4d))
+#define INSN_CMPLE (INSN_OP(0x10) | INSN_FUNC2(0x6d))
+#define INSN_CMPULT(INSN_OP(0x10) | INSN_FUNC2(0x1d))
+#define INSN_CMPULE(INSN_OP(0x10) | INSN_FUNC2(0x3d))
+#define INSN_MULL (INSN_OP(0x13) | INSN_FUNC2(0))
+#define INSN_MULQ (INSN_OP(0x13) | INSN_FUNC2(0x20))
+#define INSN_AND (INSN_OP(0x11) | INSN_FUNC2(0))
+#define INSN_BIS (INSN_OP(0x11) | INSN_FUNC2(0x20))
+#define INSN_XOR (INSN_OP(0x11) | INSN_FUNC2(0x40))
+#define
[Qemu-devel] [PATCH 2/3] Move out option lookup into a separate function
Signed-off-by: Anthony Liguori
---
vl.c | 72 +++--
1 files changed, 43 insertions(+), 29 deletions(-)
diff --git a/vl.c b/vl.c
index e070ec9..e00ae0d 100644
--- a/vl.c
+++ b/vl.c
@@ -4658,6 +4658,46 @@ static int debugcon_parse(const char *devname)
return 0;
}
+static const QEMUOption *lookup_opt(int argc, char **argv,
+const char **poptarg, int *poptind)
+{
+const QEMUOption *popt;
+int optind = *poptind;
+char *r = argv[optind];
+const char *optarg;
+
+optind++;
+/* Treat --foo the same as -foo. */
+if (r[1] == '-')
+r++;
+popt = qemu_options;
+for(;;) {
+if (!popt->name) {
+fprintf(stderr, "%s: invalid option -- '%s'\n",
+argv[0], r);
+exit(1);
+}
+if (!strcmp(popt->name, r + 1))
+break;
+popt++;
+}
+if (popt->flags & HAS_ARG) {
+if (optind >= argc) {
+fprintf(stderr, "%s: option '%s' requires an argument\n",
+argv[0], r);
+exit(1);
+}
+optarg = argv[optind++];
+} else {
+optarg = NULL;
+}
+
+*poptarg = optarg;
+*poptind = optind;
+
+return popt;
+}
+
int main(int argc, char **argv, char **envp)
{
const char *gdbstub_dev = NULL;
@@ -4672,7 +4712,7 @@ int main(int argc, char **argv, char **envp)
int cyls, heads, secs, translation;
QemuOpts *hda_opts = NULL, *opts;
int optind;
-const char *r, *optarg;
+const char *optarg;
const char *loadvm = NULL;
QEMUMachine *machine;
const char *cpu_model;
@@ -4753,38 +4793,12 @@ int main(int argc, char **argv, char **envp)
for(;;) {
if (optind >= argc)
break;
-r = argv[optind];
-if (r[0] != '-') {
+if (argv[optind][0] != '-') {
hda_opts = drive_add(argv[optind++], HD_ALIAS, 0);
} else {
const QEMUOption *popt;
-optind++;
-/* Treat --foo the same as -foo. */
-if (r[1] == '-')
-r++;
-popt = qemu_options;
-for(;;) {
-if (!popt->name) {
-fprintf(stderr, "%s: invalid option -- '%s'\n",
-argv[0], r);
-exit(1);
-}
-if (!strcmp(popt->name, r + 1))
-break;
-popt++;
-}
-if (popt->flags & HAS_ARG) {
-if (optind >= argc) {
-fprintf(stderr, "%s: option '%s' requires an argument\n",
-argv[0], r);
-exit(1);
-}
-optarg = argv[optind++];
-} else {
-optarg = NULL;
-}
-
+popt = lookup_opt(argc, argv, &optarg, &optind);
switch(popt->index) {
case QEMU_OPTION_M:
machine = find_machine(optarg);
--
1.6.5.2
[Qemu-devel] [PATCH 1/3] Support --sysconfdir in configure to specify path to configuration files (v2)
The default value is ${prefix}/etc/qemu. --sysconfdir can be used to override
the default to an absolute path. The expectation is that when installed to
/usr, --sysconfdir=/etc/qemu will be used.
Signed-off-by: Anthony Liguori
---
v1 -> v2
- rename to sysconf
---
configure | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/configure b/configure
index 5631bbb..7f8c636 100755
--- a/configure
+++ b/configure
@@ -32,6 +32,7 @@ cpu=""
prefix=""
interp_prefix="/usr/gnemul/qemu-%M"
static="no"
+sysconfdir=""
sparc_cpu=""
cross_prefix=""
cc="gcc"
@@ -453,6 +454,8 @@ for opt do
;;
--static) static="yes"
;;
+ --sysconfdir) sysconfdir="$optarg"
+ ;;
--disable-sdl) sdl="no"
;;
--enable-sdl) sdl="yes"
@@ -686,6 +689,7 @@ echo " --extra-ldflags=LDFLAGS append extra linker flags
LDFLAGS"
echo " --make=MAKE use specified make [$make]"
echo " --install=INSTALLuse specified install [$install]"
echo " --static enable static build [$static]"
+echo " --sysconfdir=PATHinstall config in PATH"
echo " --enable-debug-tcg enable TCG debugging"
echo " --disable-debug-tcg disable TCG debugging (default)"
echo " --enable-debug enable common debug build options"
@@ -1828,6 +1832,7 @@ if test "$mingw32" = "yes" ; then
fi
mansuffix=""
datasuffix=""
+ confsuffix=""
docsuffix=""
binsuffix=""
else
@@ -1838,6 +1843,9 @@ else
datasuffix="/share/qemu"
docsuffix="/share/doc/qemu"
binsuffix="/bin"
+ if test -z "$sysconfdir" ; then
+ sysconfdir="${prefix}/etc/qemu"
+ fi
fi
echo "Install prefix$prefix"
@@ -1914,6 +1922,7 @@ printf " '%s'" "$0" "$@" >> $config_host_mak
echo >> $config_host_mak
echo "CONFIG_QEMU_SHAREDIR=\"$prefix$datasuffix\"" >> $config_host_mak
+echo "CONFIG_QEMU_SYSCONFDIR=\"$sysconfdir\"" >> $config_host_mak
case "$cpu" in
i386|x86_64|alpha|cris|hppa|ia64|m68k|microblaze|mips|mips64|ppc|ppc64|s390|s390x|sparc|sparc64)
@@ -2159,6 +2168,7 @@ echo "prefix=$prefix" >> $config_host_mak
echo "bindir=\${prefix}$binsuffix" >> $config_host_mak
echo "mandir=\${prefix}$mansuffix" >> $config_host_mak
echo "datadir=\${prefix}$datasuffix" >> $config_host_mak
+echo "sysconfdir=$sysconfdir" >> $config_host_mak
echo "docdir=\${prefix}$docsuffix" >> $config_host_mak
echo "MAKE=$make" >> $config_host_mak
echo "INSTALL=$install" >> $config_host_mak
--
1.6.5.2
[Qemu-devel] Introduce global config (v2)
This series introduces global config files stored in /etc/qemu. There is both a common config (qemu.conf) and a per-target config (target-.conf). I've removed the default device bits from the series as it requires some more thought on how to best integrate it. That makes this series rather simple.
[Qemu-devel] [PATCH 3/3] Load global config files by default (v2)
A new option, -nodefconfig is introduced to prevent loading from the default
config location. Otherwise, two configuration files will be searched for,
qemu.conf and target-.conf.
To ensure that the default configuration is overridden by a user specified
config, we introduce a two stage option parsing mechanism.
Signed-off-by: Anthony Liguori
---
v1->v2
- Introduce two stage option parsing to make sure global config file is
overridden by command line options
---
qemu-options.hx |9 +
vl.c| 39 +++
2 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index ee60d8a..9294e07 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1965,6 +1965,15 @@ STEXI
@item -writeconfig @var{file}
Write device configuration to @var{file}.
ETEXI
+DEF("nodefconfig", 0, QEMU_OPTION_nodefconfig,
+"-nodefconfig\n"
+"do not load default config files at startup\n")
+STEXI
+...@item -nodefconfig
+Normally QEMU loads a configuration file from @var{sysconfdir}/qemu.conf and
+...@var{sysconfdir}/targ...@var{arch}.conf on startup. The @code{-nodefconfig}
+option will prevent QEMU from loading these configuration files at startup.
+ETEXI
HXCOMM This is the last statement. Insert new options before this line!
STEXI
diff --git a/vl.c b/vl.c
index e00ae0d..a90c330 100644
--- a/vl.c
+++ b/vl.c
@@ -4730,6 +4730,7 @@ int main(int argc, char **argv, char **envp)
#endif
CPUState *env;
int show_vnc_port = 0;
+int defconfig = 1;
init_clocks();
@@ -4789,6 +4790,44 @@ int main(int argc, char **argv, char **envp)
tb_size = 0;
autostart= 1;
+/* first pass of option parsing */
+optind = 1;
+while (optind < argc) {
+if (argv[optind][0] != '-') {
+/* disk image */
+continue;
+} else {
+const QEMUOption *popt;
+
+popt = lookup_opt(argc, argv, &optarg, &optind);
+switch (popt->index) {
+case QEMU_OPTION_nodefconfig:
+defconfig=0;
+break;
+}
+}
+}
+
+if (defconfig) {
+FILE *fp;
+fp = fopen(CONFIG_QEMU_SYSCONFDIR "/qemu.conf", "r");
+if (fp) {
+if (qemu_config_parse(fp) != 0) {
+exit(1);
+}
+fclose(fp);
+}
+
+fp = fopen(CONFIG_QEMU_SYSCONFDIR "/target-" TARGET_ARCH ".conf", "r");
+if (fp) {
+if (qemu_config_parse(fp) != 0) {
+exit(1);
+}
+fclose(fp);
+}
+}
+
+/* second pass of option parsing */
optind = 1;
for(;;) {
if (optind >= argc)
--
1.6.5.2
[Qemu-devel] Re: [PATCH 1/3] Support --sysconfdir in configure to specify path to configuration files (v2)
On 01/22/2010 05:09 PM, Anthony Liguori wrote:
The default value is ${prefix}/etc/qemu. --sysconfdir can be used to override
the default to an absolute path. The expectation is that when installed to
/usr, --sysconfdir=/etc/qemu will be used.
Sorry for not being precise; --sysconfdir in Autoconf is just ${prefix}/etc.
Paolo
[Qemu-devel] Re: [PATCH 1/3] Support --sysconfdir in configure to specify path to configuration files (v2)
On 01/22/2010 10:32 AM, Paolo Bonzini wrote:
On 01/22/2010 05:09 PM, Anthony Liguori wrote:
The default value is ${prefix}/etc/qemu. --sysconfdir can be used to
override
the default to an absolute path. The expectation is that when
installed to
/usr, --sysconfdir=/etc/qemu will be used.
Sorry for not being precise; --sysconfdir in Autoconf is just
${prefix}/etc.
That's tough for us because on Windows, we store everything in a single
directory. That is, ${sysconfdir}/qemu wouldn't be a good base for us.
We would need to have sysconfdir and then a confdir that we could make
different for win32.
Regards,
Anthony Liguori
Paolo
[Qemu-devel] Re: [PATCH 1/3] Support --sysconfdir in configure to specify path to configuration files (v2)
That's tough for us because on Windows, we store everything in a single
directory. That is, ${sysconfdir}/qemu wouldn't be a good base for us.
We would need to have sysconfdir and then a confdir that we could make
different for win32.
That makes sense. sysconf for system, conf for qemu.
Paolo
[Qemu-devel] Re: [PATCH v2 0/8] Convert migrate_set_speed, migrate_set_downtime to QObject
I'll respin this series.
Re: [Qemu-devel] [RFC 00/11]: QMP feature negotiation support
On 01/21/2010 03:09 PM, Luiz Capitulino wrote:
"""
{"QMP": {"capabilities": ["async messages"]}}
{ "execute": "query-qmp-mode" }
{"return": {"mode": "handshake"}}
{ "execute": "change", "arguments": { "device": "vnc", "target": "password", "arg":
"1234" } }
{"error": {"class": "QMPInvalidModeCommad", "desc": "The issued command is invalid in this
mode", "data": {}}}
{ "execute": "async_msg_enable", "arguments": { "name": "STOP" } }
{"return": {}}
Maybe:
enable-capability "async messages"
disable-capability "async messages"
I think that's a bit more obvious and it means that a client doesn't
have to maintain a mapping of features -> enable functions. It's also
strange to use an enable command to disable something.
Regards,
Anthony Liguori
[Qemu-devel] Re: sparc32 do_unassigned_access overhaul
On Tue, Jan 19, 2010 at 9:44 PM, Artyom Tarasenko wrote: > 2010/1/19 Blue Swirl : >> On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko >> wrote: >>> 2010/1/15 Artyom Tarasenko : 2010/1/15 Blue Swirl : > On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko > wrote: >> 2010/1/15 Blue Swirl : >>> On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko >>> wrote: According to pages 9-31 - 9-34 of "SuperSPARC & MultiCache Controller User's Manual": 1. "A lower priority fault may not overwrite the MFSR status of a higher priority fault." 2. The MFAR is overwritten according to the policy defined for the MFSR 3. The overwrite bit is asserted if the fault status register (MFSR) has been written more than once by faults of the same class 4. SuperSPARC will never place instruction fault addresses in the MFAR. Implementation of points 1-3 allows booting Solaris 2.6 and 2.5.1. >>> >>> Nice work! This also passes my tests. >> >> I'm afraid we still are not there yet though: Solaris 7 fails >> potentially due to >> another bug in the MMU emulation, and the initial [missing-] RAM >> detection in OBP fails >> very probably due to a bug in in the MMU emulation. > > Some guesses: > - Access to unassigned RAM area may be handled by the memory > controller differently (no faults, different faults etc.) than > unassigned access to SBus or other area. >>> >>> You are right! It seems to be true for the area larger than max RAM though. >>> On a real SS-5 with 32M in the first bank, no fault is produced at >>> least for the areas >>> 0-0x2fff, 0x7000-0xafff (ha, this would solve problems >>> with SS-20 OBP >>> too) and 0xf000-0xf6ff. >> >> The fault may still be recorded somewhere else (MXCC, RAM/ECC >> controller or IOMMU). > > sfar and sfsr were empty, so it's definitely not MXCC. Don't know > where to look for the other two. > > But how the fault would be generated? Don't know about Sun simms, but > PC ones don't have any handshake. IMHO the ECC can be the only > possibility. > >> OBP may have disabled the fault, or it has not >> enabled fault generation. > > NF bit is not set. Also, you can see the other faults. > >> On SS-5, the physical address space should be only 31 bits, so you >> should see RAM aliased at 0x8000. > > No. The RAM can be aliased only within one bank or completely outside > the RAM area. Otherwise different banks would have interfered. > >>> Would you like to implement it? >> >> For RAM, there could be a new device which implements generic address >> space wrapping (base, length, AND mask, OR mask), it should be useful >> for embedded boards. Shouldn't be too difficult, want to try? :-) > > Minutes for you, days for me. :) Here's my patch. It implements mapping of bottom 2G to upper 2G. Could you play with the patch and try to implement RAM aliasing so that OBP is content? 0001-Add-generic-address-space-aliasing-mechanism-and-use.patch Description: application/mbox
Re: [Qemu-devel] [PATCH] Porting TCG to alpha platform
On 01/22/2010 07:47 AM, identifier scorpio wrote:
Is there any good method to find the bug except "guess and try"?
-singlestep -d in_asm,cpu,exec
Use these options on both Alpha host and x86_64 host and diff the
resulting output files. That will show you which target instruction is
emulated differently.
And it seems that few people is interested in porting QEMU/TCG to
alpha platform, why? just because alpha machine is disappearing?
Probably. I no longer have functioning alpha hardware, which is why
I've become interested in qemu with alpha as a target.
+tcg_out32(s, (opc)|INSN_RA(ra)|INSN_DISP21(disp));
Coding style: spaces around operators, no useless parens around opc.
+static inline int tcg_target_const_match( \
+tcg_target_long val, const TCGArgConstraint *arg_ct)
Coding style: no trailing \; there's no need for line continuation
anywhere except in preprocessor directives. Merge the first argument
into the first line, assuming that can happen without exceeding 80
columns. Arguments that do get split to subsequent lines should be
properly indented below the first argument on the previous line.
+if ( type == TCG_TYPE_I32)
+val = (int32_t)val;
Coding style: use braces, even for a single statement. Yes, there's
plenty of code in the project that doesn't, but the coding style is
being enforced on all new code.
Also, extra space after open paren.
+if (disp != (int16_t)disp) {
+tcg_out_movi(s, TCG_TYPE_I64, TMP_REG1, disp);
+tcg_out_fmt_opr(s, INSN_ADDQ, rb, TMP_REG1, TMP_REG1);
+tcg_out_fmt_mem(s, opc, ra, TMP_REG1, 0);
+} else {
+tcg_out_fmt_mem(s, opc, ra, rb, disp);
+}
The reason I suggested writing the tcg_out_opc_long as I did was so that
for a 32-bit displacement like 0x12345678 instead of
ldah $28,0x1234($31)
lda $28,0x5678($28)
addq $16,$28,$28
ldq $17,0($28)
we can generate
ldah $28,0x1234($16)
ldq $17,0x5678($28)
For larger 64-bit constants obviously we have no choice but to use an
ADDQ, but even then one can stuff the final 16-bit addition into the
memory insn itself.
Given the size of the CPUState, offsets > 32k are very common, so it
would be good to handle this case well.
+static void tcg_out_mov_addr( TCGContext *s, int ret, int addr)
+{
+tcg_out_mov(s, ret, addr);
+#if TARGET_LONG_BITS == 32
+/* if VM is of 32-bit arch, clear higher 32-bit of addr */
+tcg_out_fmt_opi(s, INSN_ZAPNOT, ret, 0x0f, ret);
+#endif
+}
It's a bit wasteful to emit the move *and* the zap; give "addr" to the
first operand of the zapnot directly.
+tgen_arithi(s, INSN_ADDQ, r1, offsetof(CPUState,
tlb_table[mem_index][0].addr_read));
+tcg_out_fmt_opr(s, INSN_ADDQ, r1, TCG_REG_15, r1);
+#if TARGET_LONG_BITS == 32
+tcg_out_fmt_mem(s, INSN_LDL, TMP_REG1, r1, 0);
+tcg_out_fmt_opi(s, INSN_ZAPNOT, TMP_REG1, 0x0f, TMP_REG1);
+#else
+tcg_out_fmt_mem(s, INSN_LDQ, TMP_REG1, r1, 0);
+#endif
Better as
tcg_out_fmt_opr(s, INSN_ADDQ, r1, TCG_REG_15, r1);
tcg_out_ldst(s, TARGET_LONG_BITS == 32 ? INSN_LDL : INSN_LDQ,
TMP_REG1, r1, offsetof(CPUState, ...), 0);
to fold part of the offset into the memory displacement, and reuse your
existing code emitting the zapnot.
You might also consider copying the ppc64 port and split out a
tcg_out_tlb_read function from both qemu_ld and qemu_st.
+*(uint32_t *)label1_ptr = (uint32_t) \
+( INSN_BNE | ( TMP_REG1 << 21 ) | ( val & 0x1f));
If you're not going to use the gen_new_label method, at least use your
INSN_RA and INSN_DISP21 macros.
+tcg_out_movi(s, TCG_TYPE_I64, TMP_REG1, \
+ offsetof(CPUTLBEntry, addend) - offsetof(CPUTLBEntry, addr_read));
+tcg_out_fmt_opr(s, INSN_ADDQ, r1, TMP_REG1, r1);
+tcg_out_fmt_mem(s, INSN_LDQ, TMP_REG1, r1, 0);
As above, better to use tcg_out_ldst.
+{ INDEX_op_add_i32, { "r", "0", "r" } },
All of these matching constraints are wrong -- alpha is a 3 address
machine; should be { "r", "r", "r" }, at least until you support
constant arguments properly.
I still haven't seen anything that looks actively wrong to explain why
windows isn't working for you...
r~
Re: [Qemu-devel] [PATCH 08/11] QMP: Asynchronous messages enable/disable support
On 01/21/2010 03:09 PM, Luiz Capitulino wrote: This commit disables asynchronous messages by default and introduces two new QMP commands: async_msg_enable and async_msg_disable. Each QMP Monitor has its own set of asynchronous messages, so for example, if QEMU is run with two QMP Monitors async messages setup in one of them doesn't affect the other. To implement this design a bitmap is introduced to the Monitor struct, each async message is represented by one bit. Signed-off-by: Luiz Capitulino Ah, I see I was a little confused. I'd suggest making async message masking an independent mechanism. Capabilities should strictly deal with protocol changes, not feature details. For instance, protocol timestamps are something would reasonable considered a capability. Extended data types would be a capability. Another way to look at it, is that if you're writing a client library, the capability negotiation should be entirely invisible to the end API user. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] loader: don't call realloc(O) when no symbols are present
On Fri, 22 Jan 2010, Markus Armbruster wrote: > malc writes: > > > On Thu, 21 Jan 2010, Jamie Lokier wrote: > > > >> Markus Armbruster wrote: > >> > malc writes: > >> > > >> > > On Tue, 29 Dec 2009, Jamie Lokier wrote: > >> > > > >> > >> malc wrote: > >> > >> > On Mon, 28 Dec 2009, Jamie Lokier wrote: > >> > >> > > >> > >> > > Aurelien Jarno wrote: > >> > >> > > > This fixes the loading of a stripped kernel with zero malloc > >> > >> > > > disabled. > >> > >> > > > >> > >> > > *Raises an eyebrow* > >> > >> > > > >> > >> > > Even though there's different perspectives over whether > >> > >> > > qemu_malloc(0) > >> > >> > > should be allowed, inherited from ambiguity over malloc(0), > >> > >> > > realloc(p,0) has always had a standard, well-defined meaning. > >> > >> > > >> > >> > No. > >> > >> > http://groups.google.com/group/comp.std.c/browse_thread/thread/4e9af8847613d71f/6f75ad22e0768a0b?q=realloc++group:comp.std.c#6f75ad22e0768a0b > >> > >> > >> > >> Wow, thanks for that. It's a real surprise. Looks like C99's own > >> > >> rationale is not consistent with itself on the subject, and differs > >> > >> from C90 where the "standard, well-defined meaning" I referred to was > >> > >> defined. > >> > > > >> > > Yep. > >> > > >> > No, this is a misinterpretation of the C99 standard, made possible by > >> > its poor wording. The C99 Rationale is perfectly clear, though: > >> > > >> > 7.20.3.4 The realloc function > >> > > >> > A null first argument is permissible. If the first argument is not > >> > null, and the second argument is 0, then the call frees the memory > >> > pointed to by the first argument, and a null argument may be > >> > returned; [...] > >> > >> The rationale above does not match C89 behaviour. It says the call > >> frees the memory, but it does not forbid the call from then proceeding > >> to do the same as malloc(0) and return a non-NULL pointer. It's quite > >> explicit: a null argument *may* be returned. Which means the > >> rationale does not require realloc(p,0) to do the same as C89, which > >> always frees the memory and doesn't allocate anything. > >> > >> > This is hardly surprising, because anything else would break working C89 > >> > programs, and that would squarely contradict the standard's mission, > >> > >> Understood. But it doesn't really matter what's intended or what's > >> misinterpreted. If there are any significant implementations out > >> there based on the "misinterpretation", or even based on the > >> rationale, that's enough of a reason to not depend on realloc(p,0). > >> > > > > My sentiment exactly. > > > > An example: > > > > Dinkum Unabridged Library was certified by Perennial > > (http://peren.com/pages/aboutus_set.htm) to conform > > to ISO/IEC 9899:1999. > > > > Documentation for realloc: > > http://www.dinkumware.com/manuals/?manual=compleat&Search=realloc&page=stdlib.html#realloc > > > > Hallvard B Furuseth analysis fully applies i believe... > > Regardless of whether his analysis applies to this implementation's > documentation or not: what does this implementation actually do? > I'd guess it follows it's own documentation, but i don't have it to check, anyone? -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] loader: don't call realloc(O) when no symbols are present
On Fri, 22 Jan 2010, Markus Armbruster wrote: > malc writes: > > > On Thu, 21 Jan 2010, Markus Armbruster wrote: > > > >> malc writes: > >> > >> > On Thu, 21 Jan 2010, Markus Armbruster wrote: > > > > [..snip..] > > > >> >> No, this is a misinterpretation of the C99 standard, made possible by > >> >> its poor wording. The C99 Rationale is perfectly clear, though: > >> > > >> > You have to show the flaw in Hallvard B Furuseth's analysis to claim > >> > that it's a misinterpretation. And unlike the standard rationale is > >> > non normative. > >> > > >> > [..snip..] > >> > >> I did. If that doesn't convince you, I'll gladly wait for the Technical > >> Corrigendum that'll put this rather absurd misreading to rest. > > > > If you did, then, i guess, i've missed it, here's the whole analysis, > > please point what and where is wrong: > > > > [quote: > > http://groups.google.com/group/comp.std.c/browse_thread/thread/4e9af8847613d71f/6f75ad22e0768a0b?q=realloc++group:comp.std.c#6f75ad22e0768a0b] > > > > C90 said realloc(non-null, 0) did free(). C99 inverted that, saying it > > does not: > > > > The only place where 7.20.3.4 (The realloc function) mentions that > > realloc may free the old object, is in the case where it returns another > > object. > > 7.20.3.4 starts with the simple, unconditional statement: > > The realloc function deallocates the old object pointed to by ptr > and returns a pointer to a new object that has the size specified by > size. > > The only place where it limits this clause is here: > > If memory for the new object cannot be allocated, the old object is > not deallocated and its value is unchanged. > > Therefore, saying that realloc() frees the old object only when "it > returns another object" is imprecise. What the standard *actually* says > is realloc() frees unless "the new object cannot be allocated". It says, btw for some reason you've snipped the last part of the paragraph in one of you previous posts: Returns [#4] The realloc function returns a pointer to the new | object (which may have the same value as a pointer to the | old object), or a null pointer if the new object could not | ^ be allocated. ^ ^^ marks what you've snipped and under this GLIBC's behaviour is in error, since a. GLIBC returns NULL, which is only sanctioned if the new object is not allocated b. From a) and #4 follows that the old object wasn't freed > > The question is whether returning null for a zero-sized allocation is to > be considered "the new object cannot be allocated". The claim that > realloc(p, 0) may not free(p) relies on the answer to that question > being "yes". And the answer is "yes" if one follows simple logic. > However, the Rationale maintains that the answer is "no". Which is > consistent with the previous iteration of the standard, common usage > predating the standard, and thus with the standard's mission to avoid > "quiet changes". We really have to wait for TC. [..snip..] > > If your reading of the standard leads to conclusions like "breaks most > existing programs in an unfixable way", in absence of any evidence of > such breakage in practice, then it's maybe time to double-check it > against the Rationale. > > If C99 made the sky fall, we'd be done being crushed by now :) > -- mailto:av1...@comtv.ru
[Qemu-devel] [RFC] New API for asynchronous monitor commands
Qemu has a number of commands that can operate asynchronously (savevm, migrate,
etc) and it will be getting more. For these commands, the user monitor needs
to be suspended, but QMP monitors could continue to to accept other commands.
This patch introduces a new command API that isolates the details of handling
different monitor types from the actual command execution.
A monitor command can use this API by implementing the mhandler.cmd_async
handler (or info_async if appropriate). This function is responsible for
submitting the command and does not return any data although it may raise
errors. When the command completes, the QMPCompletion callback should be
invoked with its opaque data and the command result.
The process for submitting and completing an asynchronous command is different
for QMP and user monitors. A user monitor must be suspended at submit time and
resumed at completion time. The user_print() function must be passed to the
QMPCompletion callback so the result can be displayed properly. QMP monitors
are simpler. No submit time setup is required. When the command completes,
monitor_protocol_emitter() writes the result in JSON format.
This API can also be used to implement synchronous commands. In this case, the
cmd_async handler should immediately call the QMPCompletion callback. It is my
hope that this new interface will work for all commands, leading to a
drastically simplified monitor.c once all commands are ported.
Thanks to Anthony for helping me out with the initial design.
Signed-off-by: Adam Litke
To: Anthony Liguori
cc: Luiz Capitulino
Cc: qemu-devel@nongnu.org
diff --git a/monitor.c b/monitor.c
index cadf422..c0d0fa9 100644
--- a/monitor.c
+++ b/monitor.c
@@ -76,6 +76,12 @@
*
*/
+typedef struct UserQMPCompletionData UserQMPCompletionData;
+struct UserQMPCompletionData {
+Monitor *mon;
+void (*user_print)(Monitor *mon, const QObject *data);
+};
+
typedef struct mon_cmd_t {
const char *name;
const char *args_type;
@@ -85,11 +91,19 @@ typedef struct mon_cmd_t {
union {
void (*info)(Monitor *mon);
void (*info_new)(Monitor *mon, QObject **ret_data);
+int (*info_async)(Monitor *mon, QMPCompletion *cb, void *opaque);
void (*cmd)(Monitor *mon, const QDict *qdict);
void (*cmd_new)(Monitor *mon, const QDict *params, QObject **ret_data);
+int (*cmd_async)(Monitor *mon, const QDict *params,
+ QMPCompletion *cb, void *opaque);
} mhandler;
+int async;
} mon_cmd_t;
+static void do_async_info_handler(Monitor *mon, const mon_cmd_t *cmd);
+static void do_async_cmd_handler(Monitor *mon, const mon_cmd_t *cmd,
+ const QDict *params);
+
/* file descriptors passed via SCM_RIGHTS */
typedef struct mon_fd_t mon_fd_t;
struct mon_fd_t {
@@ -255,6 +269,11 @@ static inline int monitor_handler_ported(const mon_cmd_t
*cmd)
return cmd->user_print != NULL;
}
+static inline bool monitor_handler_is_async(const mon_cmd_t *cmd)
+{
+return cmd->async != 0;
+}
+
static inline int monitor_has_error(const Monitor *mon)
{
return mon->error != NULL;
@@ -453,6 +472,23 @@ static void do_commit(Monitor *mon, const QDict *qdict)
}
}
+static void user_monitor_complete(void *opaque, QObject *ret_data)
+{
+UserQMPCompletionData *data = (UserQMPCompletionData *)opaque;
+
+if (ret_data) {
+data->user_print(data->mon, ret_data);
+}
+monitor_resume(data->mon);
+qemu_free(data);
+}
+
+static void qmp_monitor_complete(void *opaque, QObject *ret_data)
+{
+Monitor *mon = (Monitor *)opaque;
+monitor_protocol_emitter(mon, ret_data);
+}
+
static void do_info(Monitor *mon, const QDict *qdict, QObject **ret_data)
{
const mon_cmd_t *cmd;
@@ -476,7 +512,15 @@ static void do_info(Monitor *mon, const QDict *qdict,
QObject **ret_data)
goto help;
}
-if (monitor_handler_ported(cmd)) {
+if (monitor_handler_is_async(cmd)) {
+do_async_info_handler(mon, cmd);
+/*
+ * Indicate that this command is asynchronous and will not return any
+ * date (not even empty). Instead, the data will be returned via a
+ * completion callback.
+ */
+*ret_data = qobject_from_jsonf("{ 'async': 'return' }");
+} else if (monitor_handler_ported(cmd)) {
cmd->mhandler.info_new(mon, ret_data);
if (!monitor_ctrl_mode(mon)) {
@@ -3612,6 +3656,11 @@ static void monitor_print_error(Monitor *mon)
mon->error = NULL;
}
+static int is_async_return(const QObject *data)
+{
+return data && qdict_haskey(qobject_to_qdict(data), "async");
+}
+
static void monitor_call_handler(Monitor *mon, const mon_cmd_t *cmd,
const QDict *params)
{
@@ -3619,7 +3668,15 @@ static void monitor_call_handler(Monitor *mon, const
mon_cmd_t *cmd,
cmd->mhandler.cmd_new(mon, params, &data);
-if (monitor_ctrl_mode(
Re: [Qemu-devel] [PATCH 08/11] QMP: Asynchronous messages enable/disable support
On Fri, 22 Jan 2010 12:05:19 -0600 Anthony Liguori wrote: > On 01/21/2010 03:09 PM, Luiz Capitulino wrote: > > This commit disables asynchronous messages by default and > > introduces two new QMP commands: async_msg_enable and > > async_msg_disable. > > > > Each QMP Monitor has its own set of asynchronous messages, > > so for example, if QEMU is run with two QMP Monitors async > > messages setup in one of them doesn't affect the other. > > > > To implement this design a bitmap is introduced to the > > Monitor struct, each async message is represented by one bit. > > > > Signed-off-by: Luiz Capitulino > > > > Ah, I see I was a little confused. > > I'd suggest making async message masking an independent mechanism. > Capabilities should strictly deal with protocol changes, not feature > details. To summarize (after a IRC talk): async messages are considered a capability and should be enabled during the negotiation phase but the masking of particular messages are not and can be done at any time after the negotiation phase. I'm ok with that, Markus?
Re: [Qemu-devel] [PATCH] sparc64: reimplement tick timers v3
On Tue, Jan 19, 2010 at 10:25 PM, Igor V. Kovalenko
wrote:
> From: Igor V. Kovalenko
>
> sparc64 timer has tick counter which can be set and read,
> and tick compare value used as deadline to fire timer interrupt.
> The timer is not used as periodic timer, instead deadline
> is set each time new timer interrupt is needed.
>
> v2 -> v3:
> - added missing timer debug output macro
> - CPUTimer struct and typedef moved to cpu.h
> - change CPU_SAVE_VERSION to 6, older save formats not supported
>
> v1 -> v2:
> - new conversion helpers cpu_to_timer_ticks and timer_to_cpu_ticks
> - save offset from clock source to implement cpu_tick_set_count
> - renamed struct sun4u_timer to CPUTimer
> - load and save cpu timers
>
> v0 -> v1:
> - coding style
My debugging of Linux panic has not been very fruitful. Once I got the
panic triggered while single stepping calibrate_delay() with GDB and
keeping enter key pressed. Then I missed the fault though.
One possible problem is that 4dc28134f3d7db0033c6b3c5bc4be9a91adb3e2b
added interrupt checks to the helpers which means that they can cause
faults, but translation of the instructions was not changed to take
this into account. But when I added calls to save_state() in
translate.c, it didn't change anything.
> -void cpu_tick_set_count(void *opaque, uint64_t count)
> +void cpu_tick_set_count(CPUTimer *timer, uint64_t count)
> {
> - ptimer_set_count(opaque, -count);
> + uint64_t real_count = count & ~timer->disabled_mask;
Formatting looks a bit odd. I'd prefer for such a short lists that '='
is close to the left hand value.
> + uint64_t disabled_bit = count & timer->disabled_mask;
> +
> + int64_t vm_clock_offset = qemu_get_clock(vm_clock) -
> + cpu_to_timer_ticks(real_count, timer->frequency);
> +
> + TIMER_DPRINTF("%s set_count count=0x%016lx (%s) p=%p\n",
> + timer->name, real_count,
> + timer->disabled?"disabled":"enabled", opaque);
opaque is wrong, should be timer. Same problem is in some other debug
messages. Timer name would be more helpful than pointer.
> +
> + timer->disabled = disabled_bit ? 1 : 0;
> + timer->clock_offset = vm_clock_offset;
Formatting.
> + TIMER_DPRINTF("%s get_count count=0x%016lx (%s) p=%p\n",
> + timer->name, real_count,
> + timer->disabled?"disabled":"enabled", opaque);
opaque
> + TIMER_DPRINTF("%s set_limit limit=0x%016lx (%s) p=%p "
> + "called with limit=0x%016lx at 0x%016lx
> (delta=0x%016lx)\n",
> + timer->name, real_limit,
> + timer->disabled?"disabled":"enabled",
> + opaque, limit,
> + timer_to_cpu_ticks(now - timer->clock_offset,
> + timer->frequency),
> + timer_to_cpu_ticks(expires - now, timer->frequency));
opaque
[Qemu-devel] Re: regression between 0.12.1.2 and 0.12.2
Toralf Förster wrote: > Hi, > > under a mostly stable Gentoo I observed this new msg : > > tfoer...@n22 ~/virtual/kvm $ qemu -hda gentoo_kdevm.img -hdb > portage_kdeprefix.img -hdd swap.img -smp 2 -m 768 -vga std -soundhw es1370 > > > BUG: kvm_dirty_pages_log_enable_slot: invalid parameters > > BUG: kvm_dirty_pages_log_disable_slot: invalid parameters > > .. > > The kvm image can be derived from > http://dev.gentooexperimental.org/~wired/kvm/ . > > My system is a : > tfoer...@n22 ~/virtual/kvm $ uname -a > Linux n22 2.6.32.4 #1 SMP Mon Jan 18 20:20:38 CET 2010 i686 Intel(R) > Core(TM)2 Duo CPU P8600 @ 2.40GHz GenuineIntel GNU/Linux > > That's a pre-0.12.1.2 qemu-kvm issue, upstream is not affected - or is at least not reporting it. It's already in my todo queue, just waiting to be dequeued. Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] Re: sparc32 do_unassigned_access overhaul
2010/1/22 Blue Swirl : > On Tue, Jan 19, 2010 at 9:44 PM, Artyom Tarasenko > wrote: >> 2010/1/19 Blue Swirl : >>> On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko >>> wrote: 2010/1/15 Artyom Tarasenko : > 2010/1/15 Blue Swirl : >> On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko >> wrote: >>> 2010/1/15 Blue Swirl : On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko wrote: > According to pages 9-31 - 9-34 of "SuperSPARC & MultiCache Controller > User's Manual": > > 1. "A lower priority fault may not overwrite the > MFSR status of a higher priority fault." > 2. The MFAR is overwritten according to the policy defined for the > MFSR > 3. The overwrite bit is asserted if the fault status register (MFSR) > has been written more than once by faults of the same class > 4. SuperSPARC will never place instruction fault addresses in the > MFAR. > > Implementation of points 1-3 allows booting Solaris 2.6 and 2.5.1. Nice work! This also passes my tests. >>> >>> I'm afraid we still are not there yet though: Solaris 7 fails >>> potentially due to >>> another bug in the MMU emulation, and the initial [missing-] RAM >>> detection in OBP fails >>> very probably due to a bug in in the MMU emulation. >> >> Some guesses: >> - Access to unassigned RAM area may be handled by the memory >> controller differently (no faults, different faults etc.) than >> unassigned access to SBus or other area. You are right! It seems to be true for the area larger than max RAM though. On a real SS-5 with 32M in the first bank, no fault is produced at least for the areas 0-0x2fff, 0x7000-0xafff (ha, this would solve problems with SS-20 OBP too) and 0xf000-0xf6ff. >>> >>> The fault may still be recorded somewhere else (MXCC, RAM/ECC >>> controller or IOMMU). >> >> sfar and sfsr were empty, so it's definitely not MXCC. Don't know >> where to look for the other two. >> >> But how the fault would be generated? Don't know about Sun simms, but >> PC ones don't have any handshake. IMHO the ECC can be the only >> possibility. >> >>> OBP may have disabled the fault, or it has not >>> enabled fault generation. >> >> NF bit is not set. Also, you can see the other faults. >> >>> On SS-5, the physical address space should be only 31 bits, so you >>> should see RAM aliased at 0x8000. >> >> No. The RAM can be aliased only within one bank or completely outside >> the RAM area. Otherwise different banks would have interfered. >> Would you like to implement it? >>> >>> For RAM, there could be a new device which implements generic address >>> space wrapping (base, length, AND mask, OR mask), it should be useful >>> for embedded boards. Shouldn't be too difficult, want to try? :-) >> >> Minutes for you, days for me. :) > > Here's my patch. It implements mapping of bottom 2G to upper 2G. Could > you play with the patch and try to implement RAM aliasing so that OBP > is content? It's a nice patch, but I'm confused. I thought that in my last mail I proved that we don't observe any RAM aliasing on SS-5. We see some ROM aliasing, but I'm not sure whether it's worth implementing. Also we see no synchronous faults on SS-5 when accessing missing memory. Haven't tested it on SS-20 yet. I'll try to get an access to a real SS-20 next week (can't have a simultaneous access to the both of them). -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
[Qemu-devel] [PATCH] arm host: Fix linker warning (m68k targets)
Compilation of m68k-softmmu or m68k-linux-user on arm host
(or cross compilation for arm) results in a linker warning:
LINK m68k-softmmu/qemu-system-m68k
m68k-dis.o: warning: definition of `floatformat_ieee_single_little' overriding
common
arm-dis.o: warning: common is here
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld:
Warning: size of symbol `floatformat_ieee_single_little' changed from 4 in
arm-dis.o to 48 in m68k-dis.o
floatformat_ieee_single_little is declared in arm-dis.c and m68k-dis.c,
and both declarations don't match, so this is an error.
The symbol is not needed in arm-dis.c, so I removed it there.
Signed-off-by: Stefan Weil
---
arm-dis.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/arm-dis.c b/arm-dis.c
index 2c67d8f..4fb899e 100644
--- a/arm-dis.c
+++ b/arm-dis.c
@@ -60,10 +60,8 @@
#define FPU_VFP_EXT_V3 0
#define FPU_NEON_EXT_V1 0
-int floatformat_ieee_single_little;
/* Assume host uses ieee float. */
-static void floatformat_to_double (int *ignored, unsigned char *data,
- double *dest)
+static void floatformat_to_double (unsigned char *data, double *dest)
{
union {
uint32_t i;
@@ -2543,9 +2541,7 @@ print_insn_neon (struct disassemble_info *info, long
given, bfd_boolean thumb)
valbytes[2] = (value >> 16) & 0xff;
valbytes[3] = (value >> 24) & 0xff;
-floatformat_to_double
- (&floatformat_ieee_single_little, valbytes,
- &fvalue);
+floatformat_to_double (valbytes, &fvalue);
func (stream, "#%.7g\t; 0x%.8lx", fvalue,
value);
--
1.6.5
[Qemu-devel] sparc32 fix np dereference in do_unassigned_access
fix a potential null pointer dereference introduced in
commit 576c2cdc767ab9e2dc038fa4c99f22e53287a3de
Signed-off-by: Artyom Tarasenko
---
diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c
index ce8c6f1..eb4f5a4 100644
--- a/target-sparc/op_helper.c
+++ b/target-sparc/op_helper.c
@@ -3761,13 +3761,14 @@ void do_unassigned_access(target_phys_addr_t addr, int
is_write, int is_exec,
else
raise_exception(TT_DATA_ACCESS);
}
-env = saved_env;
/* flush neverland mappings created during no-fault mode,
so the sequential MMU faults report proper fault types */
if (env->mmuregs[0] & MMU_NF) {
tlb_flush(env, 1);
}
+
+env = saved_env;
}
#else
void do_unassigned_access(target_phys_addr_t addr, int is_write, int is_exec,
Re: [Qemu-devel] [PATCH 08/11] QMP: Asynchronous messages enable/disable support
On 01/22/2010 02:09 PM, Luiz Capitulino wrote: On Fri, 22 Jan 2010 12:05:19 -0600 Anthony Liguori wrote: On 01/21/2010 03:09 PM, Luiz Capitulino wrote: This commit disables asynchronous messages by default and introduces two new QMP commands: async_msg_enable and async_msg_disable. Each QMP Monitor has its own set of asynchronous messages, so for example, if QEMU is run with two QMP Monitors async messages setup in one of them doesn't affect the other. To implement this design a bitmap is introduced to the Monitor struct, each async message is represented by one bit. Signed-off-by: Luiz Capitulino Ah, I see I was a little confused. I'd suggest making async message masking an independent mechanism. Capabilities should strictly deal with protocol changes, not feature details. To summarize (after a IRC talk): async messages are considered a capability and should be enabled during the negotiation phase but the masking of particular messages are not and can be done at any time after the negotiation phase. Just to further clarify, the mental model I have of capabilities is that they are things that affect the protocol itself. Additional features (new command options, new commands, new async messages) are things that are enabled/discovered in a different way. Async messages themselves are a capability since it changes the protocol. Timestamps would be another capability and a new data type (like an uint64 type) would be a new capability. I'm ok with that, Markus? Regards, Anthony Liguori
[Qemu-devel] Re: [RFC] New API for asynchronous monitor commands
On 01/22/2010 01:03 PM, Adam Litke wrote: Qemu has a number of commands that can operate asynchronously (savevm, migrate, etc) and it will be getting more. For these commands, the user monitor needs to be suspended, but QMP monitors could continue to to accept other commands. This patch introduces a new command API that isolates the details of handling different monitor types from the actual command execution. A monitor command can use this API by implementing the mhandler.cmd_async handler (or info_async if appropriate). This function is responsible for submitting the command and does not return any data although it may raise errors. When the command completes, the QMPCompletion callback should be invoked with its opaque data and the command result. The process for submitting and completing an asynchronous command is different for QMP and user monitors. A user monitor must be suspended at submit time and resumed at completion time. The user_print() function must be passed to the QMPCompletion callback so the result can be displayed properly. QMP monitors are simpler. No submit time setup is required. When the command completes, monitor_protocol_emitter() writes the result in JSON format. This API can also be used to implement synchronous commands. In this case, the cmd_async handler should immediately call the QMPCompletion callback. It is my hope that this new interface will work for all commands, leading to a drastically simplified monitor.c once all commands are ported. Thanks to Anthony for helping me out with the initial design. Signed-off-by: Adam Litke To: Anthony Liguori cc: Luiz Capitulino Cc: qemu-devel@nongnu.org I like this a lot and I'd like to see us remove cmd_new in place of cmd_async. The conversion is pretty easy since we just have to add a cb(ret_data) to the end of synchronous functions. Luiz/Markus/Avi, what do ya'll think? Regards, Anthony Liguori
[Qemu-devel] Merge qemu android
Hi, What is the step in order to get qemu android merged mainline ? http://android.git.kernel.org/?p=platform/external/qemu.git;a=summary Regards Bastien
[Qemu-devel] no sound in MusicPal with qemu 0.12.2
Hi there, I have compiled qemu 0.12.2 on an x64 ubuntu (8.10) and run MusicPal in it with SDL. MusicPal works OK but there is no sound. I have done essentially the same with qemu 0.11.1. The sound is there (thanks jki for suggesting a previous version). Please find below the configs and logs & contact me if additional info is needed. Cheers, Ondrej 1) qemu-0.12.2 === config === ./configure --enable-mixemu --audio-drv-list="alsa oss sdl esd" --target-list="arm-softmmu" Install prefix/usr/local BIOS directory/usr/local/share/qemu binary directory /usr/local/bin Manual directory /usr/local/share/man ELF interp prefix /usr/gnemul/qemu-%M Source path /home/ondrej/private/musicpal/qemu-0.12.2 C compilergcc Host C compiler gcc CFLAGS-O2 -g QEMU_CFLAGS -m64 -Wold-style-definition -Wold-style-declaration -I. -I$(SRC_PATH) -U_FORTIFY_SOURCE -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wendif-labels -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing LDFLAGS -Wl,--warn-common -m64 -g make make install install host CPU x86_64 host big endian no target list arm-softmmu tcg debug enabled no gprof enabled no sparse enabledno strip binariesyes profiler no static build no -Werror enabled no SDL support yes curses supportyes curl support no check support no mingw32 support no Audio drivers alsa oss sdl esd Extra audio cards ac97 es1370 sb16 Block whitelist Mixer emulation yes VNC TLS support no VNC SASL support no xen support no brlapi supportno bluez supportno Documentation yes NPTL support yes GUEST_BASEyes PIE user targets no vde support no IO thread no Linux AIO support no Install blobs yes KVM support no fdt support no preadv supportno fdatasync yes uuid support no === make and install === === run it === export QEMU_AUDIO_DRV=sdl export SDL_VIDEODRIVER=x11 ##export SDL_AUDIODRIVER= qemu-system-arm -M musicpal -pflash flash.image -kernel u-boot.bin -serial stdio -m 128 -redir tcp:8080::80 -redir tcp:2323::23 __ __ _ _ | \/ | __ _ _ _| | | | |\/| |/ _` | '__\ \ / / _ \ | | | | | | (_| | | \ V / __/ | | |_| |_|\__,_|_|\_/ \___|_|_| _ _ _ | | | | | __ ) ___ ___ | |_ | | | |___| _ \ / _ \ / _ \| __| | |_| |___| |_) | (_) | (_) | |_ \___/|/ \___/ \___/ \__| MARVELL MV88W8618 Rev 0x31 SOC Validation Board. Based on Feroceon Core with ARM926 LE CPU. U-Boot 1.1.1 (Apr 7 2008 - 13:51:47) Marvell Version: Maryland 23 Freecom Version: Nashville 1.47 U-Boot code: 00F0 -> 00F2B9E0 BSS: -> 00F627CC RAM Configuration: Bank #0: 32 MB Flash: 8 MB No environment found on flash, using default. In:serial Out: serial Err: serial Waiting for USB connection USB not connected Net: Please wait, this takes a while... ethernetPhyInit at 0 Port LINK FAILS, Check line connection eth0 [PRIME] No mac address set, using random mac address 00:01:DB:FF:68:56. Hit any key to stop autoboot: 0 JFFS2 loading 'uImage' to 0x40 Scanning JFFS2 FS: .. done. JFFS2 load complete: 1203756 bytes loaded to 0x40 Booting image at 0040 ... Image Name: Linux-2.6.16.16-88w8xx8 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1203692 Bytes = 1.1 MB Load Address: 8000 Entry Point: 8000 Verifying Checksum ... OK OK Starting kernel... Uncompressing Linux... done, booting the kernel. Linux version 2.6.16.16-88w8xx8 (r...@freecom.com) (gcc version 3.3.3 (DENX ELDK 3.1.1 3.3.3-9)) #393 PREEMPT Thu Apr 3 05:56:25 UTC 2008 CPU: ARM926EJ-Sid(wb) [41069265] revision 5 (ARMv5TEJ) Machine: MV88W8618-HS35 Using U-Boot release 1.1.1.23 Memory policy: ECC disabled, Data cache writeback CPU0: D VIVT write-through cache CPU0: I cache: 4096 bytes, associativity 4, 32 byte lines, 32 sets CPU0: D cache: 65536 bytes, associativity 4, 32 byte lines, 512 sets Built 1 zonelists Kernel command line: console=ttyS0,38400 root=/dev/mtdblock0 ro rootfstype=jffs2 ethaddr=00:01:DB:FF:68:56 PID hash table entries: 256 (order: 8, 4096 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 32MB = 32MB total Memory: 29268KB available (2100K code, 911K data, 92K init) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 Reserved 64 pages (page size 4096) starting from c03c for WLAN buffer pool audio_init, major is 254 ... audio set to DMA mode fc00 fc001000 2048 Rx c000 0 0 Marvell USB EHCI Host controller SCSI subsystem initialized usbcore: registered new dr
[Qemu-devel] Re: Merge qemu android
On Thu, Jan 21, 2010 at 5:27 PM, Bastien ROUCARIES wrote: > Hi, > > What is the step in order to get qemu android merged mainline ? > > http://android.git.kernel.org/?p=platform/external/qemu.git;a=summary > > Regards > > Bastien > BTW i am volonteer for the merge Diff is 20M and I ask how can I splip it... Bastien
[Qemu-devel] ldl_code definition (qemu 0.9.0)
Hi,
I'm working on Qemu (0.9.0) extension in order to interact with SystemC (for
ARM system).
I would like to know where the ldl_code function is defined.
Qemu code use it on disas_arm_insn(...) function (code below):
static void disas_arm_insn(CPUState * env, DisasContext *s)
{
unsigned int cond, insn, val, op1, i, shift, rm, rs, rn, rd, sh;
insn = ldl_code(s->pc);
s->pc += 4;
...
}
Grep shows me that cpu-all.h contains a definition for this function (code
below):
#define ldl_code(p) ldl_raw(p)
but commenting it compilation process still work fine.
So, where really is located ldl_code function definition?
___Dott. Saul Saggin___
EDALab - Network Embedded Systems
Dip. di Informatica, Universita' degli Studi di Verona
Strada le Grazie, 15 - 37134 Verona (Italy)
email: saul.sag...@edalab.it
tel. : +39 045 802 70 85
fax : +39 045 802 70 68
web : www.edalab.it
__
[Qemu-devel] QEMU support for ARM security features / TrustZone
Hi all, after reading the QEMU documentation and doing a search on the internet I came to no clear statement whether QEMU's ARM emulation has also support for the ARM security features known as TrustZone. I found that QEMU emulates ARM Cortex-8 which in hardware have Trustzone support. It is unclear to me if this is the case in the version that QEMU emulates. I would be glad if someone knows more than I do, and could help me with some clarification. Thanks, Andreas
[Qemu-devel] Compiling ppc64-softmmu/translate.c breaks with --enable-debug
Hi all, when building git HEAD on an Ubuntu 9.10/64 with --enable-debug, it breaks with CCppc64-softmmu/translate.o /home/jd/qemu/target-ppc/translate.c: In function ‘gen_mfdcr’: /home/jd/qemu/target-ppc/translate.c:5568: error: incompatible type for argument 1 of ‘gen_helper_load_dcr’ /home/jd/qemu/target-ppc/helper.h:362: note: expected ‘TCGv_i32’ but argument is of type ‘TCGv_i64’ /home/jd/qemu/target-ppc/translate.c:5568: error: incompatible type for argument 2 of ‘gen_helper_load_dcr’ /home/jd/qemu/target-ppc/helper.h:362: note: expected ‘TCGv_i32’ but argument is of type ‘TCGv_i64’ /home/jd/qemu/target-ppc/translate.c: In function ‘gen_mtdcr’: /home/jd/qemu/target-ppc/translate.c:5587: error: incompatible type for argument 1 of ‘gen_helper_store_dcr’ /home/jd/qemu/target-ppc/helper.h:363: note: expected ‘TCGv_i32’ but argument is of type ‘TCGv_i64’ /home/jd/qemu/target-ppc/translate.c:5587: error: incompatible type for argument 2 of ‘gen_helper_store_dcr’ /home/jd/qemu/target-ppc/helper.h:363: note: expected ‘TCGv_i32’ but argument is of type ‘TCGv_i64’ /home/jd/qemu/target-ppc/translate.c: In function ‘gen_mfdcrx’: /home/jd/qemu/target-ppc/translate.c:5605: error: incompatible type for argument 1 of ‘gen_helper_load_dcr’ /home/jd/qemu/target-ppc/helper.h:362: note: expected ‘TCGv_i32’ but argument is of type ‘TCGv_i64’ /home/jd/qemu/target-ppc/translate.c:5605: error: incompatible type for argument 2 of ‘gen_helper_load_dcr’ /home/jd/qemu/target-ppc/helper.h:362: note: expected ‘TCGv_i32’ but argument is of type ‘TCGv_i64’ /home/jd/qemu/target-ppc/translate.c: In function ‘gen_mtdcrx’: /home/jd/qemu/target-ppc/translate.c:5623: error: incompatible type for argument 1 of ‘gen_helper_store_dcr’ /home/jd/qemu/target-ppc/helper.h:363: note: expected ‘TCGv_i32’ but argument is of type ‘TCGv_i64’ /home/jd/qemu/target-ppc/translate.c:5623: error: incompatible type for argument 2 of ‘gen_helper_store_dcr’ /home/jd/qemu/target-ppc/helper.h:363: note: expected ‘TCGv_i32’ but argument is of type ‘TCGv_i64’ /home/jd/qemu/target-ppc/translate.c: In function ‘gen_mfdcrux’: /home/jd/qemu/target-ppc/translate.c:5633: error: incompatible type for argument 1 of ‘gen_helper_load_dcr’ /home/jd/qemu/target-ppc/helper.h:362: note: expected ‘TCGv_i32’ but argument is of type ‘TCGv_i64’ /home/jd/qemu/target-ppc/translate.c:5633: error: incompatible type for argument 2 of ‘gen_helper_load_dcr’ /home/jd/qemu/target-ppc/helper.h:362: note: expected ‘TCGv_i32’ but argument is of type ‘TCGv_i64’ /home/jd/qemu/target-ppc/translate.c: In function ‘gen_mtdcrux’: /home/jd/qemu/target-ppc/translate.c:5642: error: incompatible type for argument 1 of ‘gen_helper_store_dcr’ /home/jd/qemu/target-ppc/helper.h:363: note: expected ‘TCGv_i32’ but argument is of type ‘TCGv_i64’ /home/jd/qemu/target-ppc/translate.c:5642: error: incompatible type for argument 2 of ‘gen_helper_store_dcr’ /home/jd/qemu/target-ppc/helper.h:363: note: expected ‘TCGv_i32’ but argument is of type ‘TCGv_i64’ make[1]: *** [translate.o] Fehler 1 make: *** [subdir-ppc64-softmmu] Fehler 2 j...@tabr:~/qemu$ .. just noticed doing the default build targets. If you need further information, please CC, I'm not subscribed. Greetz Joe
[Qemu-devel] Re: sparc32 do_unassigned_access overhaul
On Fri, Jan 22, 2010 at 8:51 PM, Artyom Tarasenko wrote: > 2010/1/22 Blue Swirl : >> On Tue, Jan 19, 2010 at 9:44 PM, Artyom Tarasenko >> wrote: >>> 2010/1/19 Blue Swirl : On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko wrote: > 2010/1/15 Artyom Tarasenko : >> 2010/1/15 Blue Swirl : >>> On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko >>> wrote: 2010/1/15 Blue Swirl : > On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko > wrote: >> According to pages 9-31 - 9-34 of "SuperSPARC & MultiCache Controller >> User's Manual": >> >> 1. "A lower priority fault may not overwrite the >> MFSR status of a higher priority fault." >> 2. The MFAR is overwritten according to the policy defined for the >> MFSR >> 3. The overwrite bit is asserted if the fault status register (MFSR) >> has been written more than once by faults of the same class >> 4. SuperSPARC will never place instruction fault addresses in the >> MFAR. >> >> Implementation of points 1-3 allows booting Solaris 2.6 and 2.5.1. > > Nice work! This also passes my tests. I'm afraid we still are not there yet though: Solaris 7 fails potentially due to another bug in the MMU emulation, and the initial [missing-] RAM detection in OBP fails very probably due to a bug in in the MMU emulation. >>> >>> Some guesses: >>> - Access to unassigned RAM area may be handled by the memory >>> controller differently (no faults, different faults etc.) than >>> unassigned access to SBus or other area. > > You are right! It seems to be true for the area larger than max RAM > though. > On a real SS-5 with 32M in the first bank, no fault is produced at > least for the areas > 0-0x2fff, 0x7000-0xafff (ha, this would solve problems > with SS-20 OBP > too) and 0xf000-0xf6ff. The fault may still be recorded somewhere else (MXCC, RAM/ECC controller or IOMMU). >>> >>> sfar and sfsr were empty, so it's definitely not MXCC. Don't know >>> where to look for the other two. >>> >>> But how the fault would be generated? Don't know about Sun simms, but >>> PC ones don't have any handshake. IMHO the ECC can be the only >>> possibility. >>> OBP may have disabled the fault, or it has not enabled fault generation. >>> >>> NF bit is not set. Also, you can see the other faults. >>> On SS-5, the physical address space should be only 31 bits, so you should see RAM aliased at 0x8000. >>> >>> No. The RAM can be aliased only within one bank or completely outside >>> the RAM area. Otherwise different banks would have interfered. >>> > Would you like to implement it? For RAM, there could be a new device which implements generic address space wrapping (base, length, AND mask, OR mask), it should be useful for embedded boards. Shouldn't be too difficult, want to try? :-) >>> >>> Minutes for you, days for me. :) >> >> Here's my patch. It implements mapping of bottom 2G to upper 2G. Could >> you play with the patch and try to implement RAM aliasing so that OBP >> is content? > > It's a nice patch, but I'm confused. I thought that in my last mail I > proved that we don't observe any RAM aliasing on SS-5. We see some ROM > aliasing, but I'm not sure whether it's worth implementing. I'd still expect some aliasing if a bank has smaller chips than others. For example, if you have 40M of memory and bank size is 16M, there are two full banks and one bank with 8M. This 8M should be aliased within the 16MB area twice. Otherwise the DRAM controller must somehow know or be told the chip size. So, the aliasing code could be useful to emulate more arbitrary memory sizes (with OBP), not just multiples of bank sizes. > Also we see no synchronous faults on SS-5 when accessing missing > memory. Haven't tested it on SS-20 yet. I'll try to get an access to a > real SS-20 next week (can't have a simultaneous access to the both of > them). Is memory parity enabled?
