[Qemu-devel] Connecting to serial console via Telnet - possible ?
Hi With SIMH, the VAX / PDP / nostalgic mini/mainframe emulator (http://simh.trailing-edge.com/) the console port on the emulated system is directed to a TCP/IP port, so that you can simply Telnet into it. Once the connection is established, then the SIMH emulator starts working. This suits SIMH nicely since many of its hosts want a VT100-ish console terminal anyhow, which is nicely emulated by many Telnet clients, and it saves SIMH having to do any keyboard conversion, host output decoding and screen output, etc. Is there a similar functionality in QEMU ? I am on a Windows host system (Win2K to be precise) and want to start QEMU with -nographic but it complains under Windows that it can't connect to stdio, which is a kind of foreign concept to Windows at times ! Any ideas ? Thanks Jason ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] MIPS instruction set configuration
Thiemo Seufer wrote: Dirk Behme wrote: Fabrice Bellard wrote: You should add a runtime selection system : see the ARM and PowerPC targets (I would prefer a parameter to cpu_init(). It was not done that way on PowerPC for legacy reasons). Each machine should be able to select the processor it needs (and allow the user to change it if needed, but it is not the main point). It might be interesting for MIPS to decouple Machine and CPU somewhat. E.g. the Malta board supports a number of different 32- and 64-bit CPUs. Each machine can add specific support for that (for example a -cpu option). It is likely to come at least for the PC machines. There is no good reason to make the selection at compile time because the translator can efficiently handle any CPU differences at runtime. I'm a bit dubious about this argument, each instruction needs to be checked agains a tuple of values. How much performance loss would be acceptable? It slows down the translator a bit, but most of the time is spent in the generated code, not in the translator (otherwise there is no point in doing dynamic translation !). [...] Unfortunately it is not that simple. We have the upward-compatible ISAs: >[...] I add suggest one more parameter to cpu_mips_set_model() to specify optional features. A function converting a CPU "string id" into an id + features would be interesting too. Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Notes on the QCOW format
Hi, I added a link from the qemu technical documentation html page. I can also commit it in the QEMU sources if you want. Regards, Fabrice. Mark McLoughlin wrote: Hi, I wrote up some notes on the QCOW format: http://www.gnome.org/~markmc/qcow-image-format.html Perhaps worth including in QEMU itself? Cheers, Mark. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Notes on the QCOW format
Hi Fabrice, If you think it's useful to have it in the sources, please do go ahead and commit it. That way others can keep it up to date, at least. Cheers, Mark. On Mon, 2006-07-03 at 10:42 +0200, Fabrice Bellard wrote: > Hi, > > I added a link from the qemu technical documentation html page. I can > also commit it in the QEMU sources if you want. > > Regards, > > Fabrice. > > Mark McLoughlin wrote: > > Hi, > > I wrote up some notes on the QCOW format: > > > > http://www.gnome.org/~markmc/qcow-image-format.html > > > > Perhaps worth including in QEMU itself? > > > > Cheers, > > Mark. > > > > > > > > ___ > > Qemu-devel mailing list > > Qemu-devel@nongnu.org > > http://lists.nongnu.org/mailman/listinfo/qemu-devel > > > > > > > > ___ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] devices and memory address
Hi all,Is it possible to reserve memory addresses in i386 qemu emulation for recognize them as device registers?ThanksAlessandro ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] MIPS instruction set configuration
Fabrice Bellard wrote: [snip] > >>>There is no good reason to make > >>>the selection at compile time because the translator can efficiently > >>>handle any CPU differences at runtime. > > > > > >I'm a bit dubious about this argument, each instruction needs to be > >checked agains a tuple of values. How much performance loss would be > >acceptable? > > It slows down the translator a bit, but most of the time is spent in the > generated code, not in the translator (otherwise there is no point in > doing dynamic translation !). Well, based on that theory I moved the CP0 register handling to dynamic translation. The patch was rejected because I had no effective method to assess the performance gain. So I wonder what the accepted tradeoffs for the implementation are. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] A question about using floppy drivers
Host OS:win98se Guest Os:Dos 7.1qemu command: Change fda D:\QEMU\test.img ;Load virtual floppy driver qemu command: info Block ;virtual floppy driver had installed After press ctrl+alt+1 key ,at Guest OS C:>A: Enter key, Guest OS still show the message: "Not ready reading drive A . Abort,Retry,Fail? " Q:why can I still not use the floppy driver? Best Regards 你 不 想 试 试 今 夏 最 “酷” 的 邮 箱 吗 ？ 蕴 涵 中 华 传 统 文 化 于 世 界 一 流 科 技 之 中，创 新 Ajax 技 术，126 “D 计 划”火 热 体 验 中 ！ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] Connecting to serial console via Telnet - possible ?
This was recently added to cvs. The next release of QEMU will have it, until then you would need to build it from cvs. -serial telnet::,server Cheers, Jason. > -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > rg] On Behalf Of Armistead, Jason > Sent: Monday, July 03, 2006 2:04 AM > To: Qemu-Devel (E-mail) > Subject: [Qemu-devel] Connecting to serial console via Telnet > - possible ? > > Hi > > With SIMH, the VAX / PDP / nostalgic mini/mainframe emulator > (http://simh.trailing-edge.com/) the console port on the > emulated system is directed to a TCP/IP port, so that you can > simply Telnet into it. Once the connection is established, > then the SIMH emulator starts working. This suits SIMH > nicely since many of its hosts want a VT100-ish console > terminal anyhow, which is nicely emulated by many Telnet > clients, and it saves SIMH having to do any keyboard > conversion, host output decoding and screen output, etc. > > Is there a similar functionality in QEMU ? > > I am on a Windows host system (Win2K to be precise) and want > to start QEMU with -nographic but it complains under Windows > that it can't connect to stdio, which is a kind of foreign > concept to Windows at times ! > > Any ideas ? > > Thanks > > Jason > > > ___ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] Connecting to serial console via Telnet - possib le ?
OK then, a question for Fabrice: how long till we see QEMU 0.8.2 released ? The current 0.8.1 version has been around for 2 months now and there are many new and exciting changes that have been added by the hard-working contributors to this list. Regards Jason Armistead -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Wessel, Jason Sent: Monday, 3 July 2006 10:01 PM To: qemu-devel@nongnu.org Subject: RE: [Qemu-devel] Connecting to serial console via Telnet - possible ? This was recently added to cvs. The next release of QEMU will have it, until then you would need to build it from cvs. -serial telnet::,server Cheers, Jason. > -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > rg] On Behalf Of Armistead, Jason > Sent: Monday, July 03, 2006 2:04 AM > To: Qemu-Devel (E-mail) > Subject: [Qemu-devel] Connecting to serial console via Telnet > - possible ? > > Hi > > With SIMH, the VAX / PDP / nostalgic mini/mainframe emulator > (http://simh.trailing-edge.com/) the console port on the > emulated system is directed to a TCP/IP port, so that you can > simply Telnet into it. Once the connection is established, > then the SIMH emulator starts working. This suits SIMH > nicely since many of its hosts want a VT100-ish console > terminal anyhow, which is nicely emulated by many Telnet > clients, and it saves SIMH having to do any keyboard > conversion, host output decoding and screen output, etc. > > Is there a similar functionality in QEMU ? > > I am on a Windows host system (Win2K to be precise) and want > to start QEMU with -nographic but it complains under Windows > that it can't connect to stdio, which is a kind of foreign > concept to Windows at times ! > > Any ideas ? > > Thanks > > Jason ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Sparc64 host support update: i386-user builds
> I got the i386-user to build by moving the troublesome SSE ops to helper > (only for Sparc32/64, no effect at least to x86 host). The emulator crashes > when executing the first TB, code generation and register use could be > suspected. The patch makes ops_sse.h more confusing to read. Any comments? Requiring that ops don't use a stack frame doesn't seem like a realistic constraint. > The remaining target specific problem with PPC FPU ops could be solved by > changing PPC to soft float. Would that be OK? The use of soft-float should be a host decision, not a target decision. All targets should be converted to use the softfloat.h interface. Hosts can then choose to use with the softfloat library or the native implementation depending on the host FP capabilities. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu/hw rtl8139.c
On Saturday 01 July 2006 22:41, Fabrice Bellard wrote: > Modified files: > hw : rtl8139.c > > Log message: > disable unimplemented C+ mode (aka windows xp 64 fix) I'm not sure I believe this. C+ mode works fine in linux, and on a simple TCP throughput test was ~20% faster. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] MIPS instruction set configuration
Thiemo Seufer wrote:
Dirk Behme wrote:
- As I understand it, MIPS III is an extension of MIPS II,
MIPS IV is an extension of MIPS III etc. Therefore I used
definitions for ISAx which include the smaller ones as well.
Unfortunately it is not that simple. We have the upward-compatible ISAs:
Mmph ;) What do you think about this: Looking at the recent
MIPS code, we have a #define MIPS_USES_R4K_EXT and a #define
MIPS_USES_FPU, nothing else. No splitting of the different
ISAs and FPU instructions at all. And, looking at your
explanation, it seems to be really tricky to do this
splitting. So I'll remove the MIPS_FEATURE_ISAx definitions
from the patch (as mentioned, they were unused and only
example), this will change nothing compared to the existing
code.
I'd prefer to make changes and improvements in small
readable pieces without changing too much. One small
improvement after the other, not a big 'perfect', but
unreadable, patch. So the splitting of the ISA levels is
something for an other patch.
The improvement of this patch is to convert the compile time
switches MIPS_USES_R4K_EXT, MIPS_USES_FPU to compile *and*
runtime switches and to make machine runtime selectable (and
introduce MIPS_FEATURE_NEC_xxx).
+enum mips_features {
+MIPS_FEATURE_ISA1 = 0x1, /* MIPS I instruction set architecture */
+MIPS_FEATURE_ISA2 = 0x3, /* MIPS II instruction set architecture */
+MIPS_FEATURE_ISA3 = 0x7, /* MIPS III instruction set architecture */
+MIPS_FEATURE_ISA4 = 0xF, /* MIPS IV instruction set architecture */
I'll remove this.
+MIPS_FEATURE_R4K_EXT = 0x10, /* instruction set extension for MIPS R4K */
Those "extensions" seem to be unimplemented, maybe this was intended to
cover partial support for MIPS32R2, IOW, for a 4KE.
Sorry, what do you mean here? I only took the existing
#define MIPS_USES_R4K_EXT.
+MIPS_FEATURE_NEC_EXT = 0x20, /* instruction set extension for NEC CPUs */
This should name the specific CPU core (vr5400 or vr5500?). NEC built
a range of MIPS CPUs (e.g. vr41xx, or R12000) with different capabilities.
Yes, I'll change this.
However, on long term, there is a 'keep code simple' vs
'split instructions technically correct' tradeoff. Adding
later switches for e.g. vr41xx and R12000 will be okay from
clean instruction split point of view, but additional
switches will mess up the code and may be doublicate some
stuff. While one MIPS_FEATURE_NEC_EXT which contains all NEC
extensions will be simple, but wrong from instruction splitting.
But I'll convert this to MIPS_FEATURE_NEC_VR5400.
+void cpu_mips_set_model(CPUMIPSState *env, uint32_t id)
+{
+env->CP0_PRid = id;
+env->features = 0;
+switch (id) {
+case MIPS_R4Kc:
+set_feature(env, MIPS_FEATURE_ISA3);
+set_feature(env, MIPS_FEATURE_R4K_EXT);
+set_feature(env, MIPS_FEATURE_FPU);
+break;
What's the meaning of "R4Kc" here?
- R4000: We don't have 64bit (ISA III) support.
- 4kc: This one has neither ISA III nor FPU.
That's easy: I don't know ;) If you look at existing
mips-defs.h it is the name of the only hardcoded machine we
have at the moment. It enables R4K extensions and FPU. It
was my goal to change no functionality, only to make first
step to runtime selection. lI'll remove the ISA option.
Best regards
Dirk
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] MIPS instruction set configuration
Fabrice Bellard wrote: Each machine can add specific support for that (for example a -cpu option). It is likely to come at least for the PC machines. ... I add suggest one more parameter to cpu_mips_set_model() to specify optional features. A function converting a CPU "string id" into an id + features would be interesting too. Fabrice, do you will accept the patch if I remove the MIPS_FEATURE_ISAx options and convert MIPS_FEATURE_NEC_EXT to MIPS_FEATURE_NEC_VR5400 as described in my previous mail? I consider this patch as a *first* step from hardcoded and compile time selected MIPS machine to flexible configuration as proposed by you and Thiemo. Other patches, for example with (really nice!) features above, can follow then and take this first patch as basis. With this, several small patches will improve MIPS step by step. I'd like to avoid a 'perfect, but unreadable, big & never ready' patch. And, with several small patches, more people can contribute ;) Many thanks for the comments Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] MIPS instruction set configuration
Dirk Behme wrote: Fabrice Bellard wrote: Each machine can add specific support for that (for example a -cpu option). It is likely to come at least for the PC machines. ... I add suggest one more parameter to cpu_mips_set_model() to specify optional features. A function converting a CPU "string id" into an id + features would be interesting too. Fabrice, do you will accept the patch if I remove the MIPS_FEATURE_ISAx options and convert MIPS_FEATURE_NEC_EXT to MIPS_FEATURE_NEC_VR5400 as described in my previous mail? Yes. Even without I can accept it as it is better than what we previously had. Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Sparc64 host support update: i386-user builds
Requiring that ops don't use a stack frame doesn't seem like a realistic constraint. It can be done, see my latest patch. Of course there's no point doing it if there is no real need. > The remaining target specific problem with PPC FPU ops could be solved by > changing PPC to soft float. Would that be OK? The use of soft-float should be a host decision, not a target decision. All targets should be converted to use the softfloat.h interface. Hosts can then choose to use with the softfloat library or the native implementation depending on the host FP capabilities. Good, I thought using softfloat.h interface implied softfloat library use. I'll make an updated Sparc64 patch without any sse mess, and separate the softfloat.h interface changes. _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] MIPS instruction set configuration
Dirk Behme wrote:
> Thiemo Seufer wrote:
> >Dirk Behme wrote:
> >>- As I understand it, MIPS III is an extension of MIPS II,
> >>MIPS IV is an extension of MIPS III etc. Therefore I used
> >>definitions for ISAx which include the smaller ones as well.
> >
> >Unfortunately it is not that simple. We have the upward-compatible ISAs:
>
> Mmph ;) What do you think about this: Looking at the recent
> MIPS code, we have a #define MIPS_USES_R4K_EXT and a #define
> MIPS_USES_FPU, nothing else. No splitting of the different
> ISAs and FPU instructions at all. And, looking at your
> explanation, it seems to be really tricky to do this
> splitting.
Somewhat complicated, but not really tricky. The OPCODE_IS_MEMBER
macro in binutils is IMHO roughly what we want to have in qemu at
some point (FPU instructions are already covered by the CP1 enabled
test). At least as long as that test doesn't slow down things too
much, for qemu this might be more relevant than for binutils.
> So I'll remove the MIPS_FEATURE_ISAx definitions
> from the patch (as mentioned, they were unused and only
> example), this will change nothing compared to the existing
> code.
>
> I'd prefer to make changes and improvements in small
> readable pieces without changing too much. One small
> improvement after the other, not a big 'perfect', but
> unreadable, patch. So the splitting of the ISA levels is
> something for an other patch.
I recommend to go for a sufficiently flexible interface first, and then
introduce it gradually in all appropriate places. A macro like:
MIPS_OPC(ISA, ASE, CPU)
which compares the arguments with the currently selected CPU emulation
and throws an RI exception if the feature doesn't exist:
...
case OPC_LD:
MIPS_OPC(MIPS-III, 0, 0);
...
break;
...
> improvement of this patch is to convert the compile time
> switches MIPS_USES_R4K_EXT, MIPS_USES_FPU to compile *and*
> runtime switches and to make machine runtime selectable (and
> introduce MIPS_FEATURE_NEC_xxx).
My point is those MIPS_USES_*/MIPS_FEATURE_* should be abstracted
better, that is, they should move in the implementation of the
MIPS_OPC macro.
This is not meant as an objection, I'm just drawing from experience
with binutils, where it took some iterations (and wasted effort) to
get it sufficiently right.
[snip]
> >>+void cpu_mips_set_model(CPUMIPSState *env, uint32_t id)
> >>+{
> >>+env->CP0_PRid = id;
> >>+env->features = 0;
> >>+switch (id) {
> >>+case MIPS_R4Kc:
> >>+set_feature(env, MIPS_FEATURE_ISA3);
> >>+set_feature(env, MIPS_FEATURE_R4K_EXT);
> >>+set_feature(env, MIPS_FEATURE_FPU);
> >>+break;
> >
> >
> >What's the meaning of "R4Kc" here?
> >- R4000: We don't have 64bit (ISA III) support.
> >- 4kc: This one has neither ISA III nor FPU.
>
> That's easy: I don't know ;) If you look at existing
> mips-defs.h it is the name of the only hardcoded machine we
> have at the moment. It enables R4K extensions and FPU. It
> was my goal to change no functionality, only to make first
> step to runtime selection. lI'll remove the ISA option.
Well, there is no CPU named "R4Kc". What qemu emulates today resembles
mostly a 4kc, that is a MIPS32R1 CPU which has no FPU support.
I figure you are going for emulation of a vr5400, a MIPS-IV CPU with
FPU and some additional multiply-add instructions.
What I hope to get done is support for MIPS32R2 including FPU, this is
close to a 24kf.
Thiemo
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] MIPS instruction set configuration
Hi all, just for information about current projects for QEMU MIPS: my machine is AR7 which includes a MIPS 4KEc core. This core supports the MIPS32R2 architecture and has no FPU. As far as I know the MIPS architecture, most CPU features can be read from well defined bits and bytes in the CP0 registers. These registers should be set by every machine definition in QEMU. So the emulation (translator) code could get all information needed from the CP0 registers which are part of variable "env". There is no need to introduce new defines or variables to get endianess, instruction set, presence of FPU or internal timer, and other features. And if generic property bits are not enough: the processor identification is part of the CP0 registers, too. Of course, one might mirror some features in extra variables for performance reasons. What do you think of my proposal? Regards Stefan Well, there is no CPU named "R4Kc". What qemu emulates today resembles mostly a 4kc, that is a MIPS32R1 CPU which has no FPU support. I figure you are going for emulation of a vr5400, a MIPS-IV CPU with FPU and some additional multiply-add instructions. What I hope to get done is support for MIPS32R2 including FPU, this is close to a 24kf. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] MIPS instruction set configuration
Stefan Weil wrote: > Hi all, > > just for information about current projects for QEMU MIPS: > > my machine is AR7 which includes a MIPS 4KEc core. > This core supports the MIPS32R2 architecture and has no FPU. > > As far as I know the MIPS architecture, most CPU features > can be read from well defined bits and bytes in the CP0 registers. > > These registers should be set by every machine definition in QEMU. > > So the emulation (translator) code could get all information needed from > the CP0 registers which are part of variable "env". There is no > need to introduce new defines or variables to get endianess, > instruction set, presence of FPU or internal timer, and other > features. This is mostly true for MIPS32 (and later) conforming CPUs. Earlier ones (like the vr5400 Dirk is interested in) didn't announce all their capabilities via config registers, and coprocessor CP0, where the config registers reside, wasn't standardised. > And if generic property bits are not enough: > the processor identification is part of the CP0 registers, too. > > Of course, one might mirror some features in extra variables for > performance reasons. > > What do you think of my proposal? It only works for the more modern CPUs. I think we have to invert the scheme, that is, keep the "master copy" of the configuration in an opaque place, and feed the config registers from there. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] RE: Connecting to serial console via Telnet - possible ?
s argument, each instruction needs to be > > checked agains a tuple of values. How much performance loss > would be > > acceptable? > > It slows down the translator a bit, but most of the time is > spent in the generated code, not in the translator (otherwise > there is no point in doing dynamic translation !). > > >[...] > > Unfortunately it is not that simple. We have the > upward-compatible ISAs: > >[...] > > I add suggest one more parameter to cpu_mips_set_model() to > specify optional features. A function converting a CPU > "string id" into an id + features would be interesting too. > > Fabrice. > > > > > -- > > Message: 3 > Date: Mon, 03 Jul 2006 10:42:46 +0200 > From: Fabrice Bellard <[EMAIL PROTECTED]> > Subject: Re: [Qemu-devel] Notes on the QCOW format > To: qemu-devel@nongnu.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii; format=flowed > > Hi, > > I added a link from the qemu technical documentation html > page. I can also commit it in the QEMU sources if you want. > > Regards, > > Fabrice. > > Mark McLoughlin wrote: > > Hi, > > I wrote up some notes on the QCOW format: > > > > http://www.gnome.org/~markmc/qcow-image-format.html > > > > Perhaps worth including in QEMU itself? > > > > Cheers, > > Mark. > > > > > > > > ___ > > Qemu-devel mailing list > > Qemu-devel@nongnu.org > > http://lists.nongnu.org/mailman/listinfo/qemu-devel > > > > > > > > > > -- > > Message: 4 > Date: Mon, 03 Jul 2006 10:04:20 +0100 > From: Mark McLoughlin <[EMAIL PROTECTED]> > Subject: Re: [Qemu-devel] Notes on the QCOW format > To: qemu-devel@nongnu.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain > > Hi Fabrice, > If you think it's useful to have it in the sources, > please do go ahead and commit it. That way others can keep it > up to date, at least. > > Cheers, > Mark. > > On Mon, 2006-07-03 at 10:42 +0200, Fabrice Bellard wrote: > > Hi, > > > > I added a link from the qemu technical documentation html > page. I can > > also commit it in the QEMU sources if you want. > > > > Regards, > > > > Fabrice. > > > > Mark McLoughlin wrote: > > > Hi, > > > I wrote up some notes on the QCOW format: > > > > > > http://www.gnome.org/~markmc/qcow-image-format.html > > > > > > Perhaps worth including in QEMU itself? > > > > > > Cheers, > > > Mark. > > > > > > > > > > > > ___ > > > Qemu-devel mailing list > > > Qemu-devel@nongnu.org > > > http://lists.nongnu.org/mailman/listinfo/qemu-devel > > > > > > > > > > > > > > ___ > > Qemu-devel mailing list > > Qemu-devel@nongnu.org > > http://lists.nongnu.org/mailman/listinfo/qemu-devel > > > > > > -- > > Message: 5 > Date: Mon, 3 Jul 2006 11:37:21 +0200 > From: "Alessandro Corradi" <[EMAIL PROTECTED]> > Subject: [Qemu-devel] devices and memory address > To: qemu-devel > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > Hi all, > Is it possible to reserve memory addresses in i386 qemu > emulation for recognize them as device registers? > > Thanks > > Alessandro > -- next part -- > An HTML attachment was scrubbed... > URL: > http://lists.gnu.org/pipermail/qemu-devel/attachments/20060703 /1b3bc4e2/attachment.html > > -- > > Message: 6 > Date: Mon, 3 Jul 2006 10:50:03 +0100 > From: Thiemo Seufer <[EMAIL PROTECTED]> > Subject: Re: [Qemu-devel] [PATCH] MIPS instruction set configuration > To: Fabrice Bellard <[EMAIL PROTECTED]> > Cc: qemu-devel@nongnu.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > Fabrice Bellard wrote: > [snip] > > >>>There is no good reason to make > > >>>the selection at compile time because the translator can > > >>>efficiently handle any CPU differences at runtime. > > > > > > > > >I'm a bit dubious about this argument, each i
[Qemu-devel] patch for handling multiple configurations on usb host devices
lo list. I've made an attempt to add support for devices with multiple configurations (and interfaces), but do not own a device to test it on. If someone with such a device could test this it would be very helpful. The patch is against CVS - the other limitations still hold true such as no devices that use isochronous endpoints (most webcams). I'm only interested in reports from those whose device does not currently work with qemu. If you have tried your usb device in the past and received: usb_host: only one interface supported then this patch will also be useful for you to test. You can find out if the device has this property from the device entry in lsusb -vv: bNumConfigurations N or from the entry in /proc/bus/usb/devices: D: Ver= 1.10 Cls=ff(vend.) Sub=ff Prot=ff MxPS= 8 #Cfgs= N where N is a number greater than 1. Please reply with the debug output from the terminal used to launch qemu and any notes you may have about the test. Thank you. qemu-multi-configs.diff.gz Description: GNU Zip compressed data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] QCow v2
Mark's notes on the qcow format got me to thinking how useful it would
be to be able to store other information in the qcow image itself. For
instance you could store the configuration for the virtual machine in
the image which could be extracted and then start the virtual machine.
So... I'm proposing that the qcow image be extended to support this
scenario. Something as simple as:
typedef struct QCowHeader {
uint32_t magic;
uint32_t version;
uint8_t embedded_data_type;
uint64_t embedded_data_offset;
uint32_t embedded_data_size;
uint32_t mtime;
uint64_t size;
uint8_t cluster_bits;
uint8_t l2_bits;
uint32_t crypt_method;
uint64_t l1_table_offset;
} QCowHeader;
Thus, embedded_data_type is a constant signifying the type of the data.
embedded_data_type could be a string, etc. Of course, there are a million
other ways this could be implemented. The idea being that we could store
more than just backing store.
One possible application could be that you could store config info in
the image and have a qemu-loader app that extracts the info and starts
the virtual machine. Another application could be just misc. metadata:
copyright, contact info, VM version, etc...
I can provide a patch to block-qcow.c if there is interest.
Nathaniel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu vlan : is IPv6 supported ?
Hi All, I was trying to setup a IPv6 network using multiple instances of qemu guests but was getting various errors The IPv4 network was working fine. (ping works but not ping6 ). Is IPv6 network possible using qemu vlan ?? Thanks Niraj ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Connecting to serial console via Telnet - possible ?
On Mon, 2006-07-03 at 03:03 -0400, Armistead, Jason wrote: > Hi > > With SIMH, the VAX / PDP / nostalgic mini/mainframe emulator > (http://simh.trailing-edge.com/) the console port on the emulated system is > directed to a TCP/IP port, so that you can simply Telnet into it. Once the > connection is established, then the SIMH emulator starts working. This > suits SIMH nicely since many of its hosts want a VT100-ish console terminal > anyhow, which is nicely emulated by many Telnet clients, and it saves SIMH > having to do any keyboard conversion, host output decoding and screen > output, etc. Well QEMU can redirect the serial port to a character device. I guess if you redirected it to a pty then you just use socat to bridge the pty to a tcp connection, telnet or whatever. -- John. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] Connecting to serial console via Telnet - possib le ?
On Tuesday, 4 July 2006 4:06 PM, John R. Hogerhuis wrote: >On Mon, 2006-07-03 at 03:03 -0400, Armistead, Jason wrote: >> Hi >> >> With SIMH, the VAX / PDP / nostalgic mini/mainframe emulator >> (http://simh.trailing-edge.com/) the console port on the emulated system is >> directed to a TCP/IP port, so that you can simply Telnet into it. Once the >> connection is established, then the SIMH emulator starts working. This >> suits SIMH nicely since many of its hosts want a VT100-ish console terminal >> anyhow, which is nicely emulated by many Telnet clients, and it saves SIMH >> having to do any keyboard conversion, host output decoding and screen >> output, etc. > >Well QEMU can redirect the serial port to a character device. I guess if >you redirected it to a pty then you just use socat to bridge the pty to >a tcp connection, telnet or whatever. That might be OK for the Unix/Linux people out there, but it's absolutely useless for Windows users (running QEMU on a Windows host), for whom socat, ptys and character devices are mostly meaningless concepts (unless you have some sort of Unix/Linux background). I'm trying to promote a more universally usable method in connecting via Telnet to the serial port - it works nicely for SIMH whether it's using a VMS, PC or Unix platform as a host. Even Microsoft decided that Telnet was worth having ! It would also be useful for anyone wanting to port QEMU to other O/S environments that do not have a Unix-style runtime environment, device files, etc. Almost anything that supports TCP/IP can offer up a port for a Telnet connection, including many embedded environments. Today, QEMU's guest machine implementations are mainly Unix-style environments based around workstation / PC / Pocket PC hardware platforms. One day, QEMU might also be a great dynamic translation / emulation environment for some more esoteric embedded devices, maybe along similar lines to MAME / MESS, and it might be running on more scaled-down host platforms rather than multi-GHz PCs with 512Mb or more of RAM. How about QEMU hosted on PS2/PS3, Xbox or PSP ? OK, so maybe I exagerate, but you get the idea ! Cheers Jason ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
