Only on a real 286. At least since 486 the legacy switch has been INIT, not
RESET.
Alexander Graf ag...@suse.de wrote:
Am 14.06.2013 um 08:56 schrieb Christian Borntraeger
borntrae...@de.ibm.com:
On 13/06/13 13:56, Anthony Liguori wrote:
Markus Armbruster arm...@redhat.com writes:
On 12/05/2013 08:08 AM, Paolo Bonzini wrote:
Il 02/12/2013 17:43, Liu, Jinsong ha scritto:
From fbfa537f690eca139a96c6b2636ab5130bf57716 Mon Sep 17 00:00:00 2001
From: Liu Jinsong jinsong@intel.com
Date: Fri, 29 Nov 2013 01:27:00 +0800
Subject: [PATCH 1/4] X86: Intel MPX definiation
No... we always ask for cpufeature.h patches separately because they sometimes
cause conflicts between branches.
Borislav Petkov b...@alien8.de wrote:
On Sat, Dec 07, 2013 at 02:52:55AM +0800, Qiaowei Ren wrote:
Signed-off-by: Qiaowei Ren qiaowei@intel.com
Signed-off-by: Xudong Hao
On 12/06/2013 08:27 AM, Liu, Jinsong wrote:
Eric Blake wrote:
On 12/06/2013 07:06 AM, Liu, Jinsong wrote:
Intel has released Memory Protection Extensions (MPX) recently.
Please refer to
http://download-software.intel.com/sites/default/files/319433-015.pdf
These 2 patches are version2 to
On 12/06/2013 05:46 AM, Borislav Petkov wrote:
I'm guessing this and the struct lwp_struct above is being added so that
you can have the LWP XSAVE area size? If so, you don't need it: LWP
XSAVE area is 128 bytes at offset 832 according to my manuals so I'd
guess having a u8 lwp_area[128]
On 12/06/2013 09:35 AM, Paolo Bonzini wrote:
Sorry for the back-and-forth, but I think this and the removal of
XSTATE_FLEXIBLE (perhaps XSTATE_LAZY?) makes your v2 worse than v1.
Since Peter already said the same, please undo these changes.
Also, how is XSTATE_EAGER used? Should MPX be
On 12/06/2013 12:05 PM, Liu, Jinsong wrote:
Since Peter already said the same, please undo these changes.
Also, how is XSTATE_EAGER used? Should MPX be disabled when xsaveopt
is disabled on the kernel command line? (Liu, how would this affect
the KVM patches, too?)
Paolo
Currently
On 12/06/2013 05:16 PM, Ren, Qiaowei wrote:
Jinsong think that both kvm and host depend on these feature definition
header file, so we firstly submit these files depended on.
Yes, but we can't turn on the feature without proper protection. Either
way, they are now in tip:x86/cpufeature.
I got a bug report today that my recent changes to the Linux kernel
setup broke the Qemu kernel loader. I implemented a workaround, but
found a number of serious bugs in the loader itself. As a consequence,
I have rewritten it; here is a patch against qemu-0.9.0.
As rewritten, it should follow
H. Peter Anvin wrote:
I got a bug report today that my recent changes to the Linux kernel
setup broke the Qemu kernel loader. I implemented a workaround, but
found a number of serious bugs in the loader itself. As a consequence,
I have rewritten it; here is a patch against qemu-0.9.0
Adam Lackorzynski wrote:
+
+/* Make sure we have a partition signature */
+bootsect[0x510] = 0x55;
+bootsect[0x511] = 0xaa;
These two should be decimal instead of hex.
Oh, yes, duh. 510 and 511 or 0x1fe and 0x1ff.
-hpa
Thiemo Seufer wrote:
CVSROOT: /sources/qemu
Module name: qemu
Changes by: Thiemo Seufer ths 07/05/20 01:34:23
Removed files:
pc-bios: linux_boot.S
Log message:
Remove leftover file, should have happened in the Linux loader rewrite
commit.
Luke -Jr wrote:
I'm sure someone's probably had a similar idea before, and it's probably not
practical for some reason I'm overlooking-- but is there a reason Qemu can't
dynamically translate library calls to use the native libraries instead of
requiring emulated libraries as well?
The
On 10/11/2010 12:51 PM, Anthony Liguori wrote:
-kernel hijacks int19 so it cannot participate in any kind of boot
order. It's either present (and therefore the bootable disk) or not
present.
That's a misdesign, though: it should be able to participate in BBS as a
BEV.
-hpa
On 10/11/2010 01:30 PM, Anthony Liguori wrote:
On 10/11/2010 02:59 PM, Gleb Natapov wrote:
No boot rom should do that. extboot wreaks havoc when it is used.
And since virtio is now supported by bios there is no reason to use it.
You don't really have a choice. You could be doing hardware
On 10/11/2010 02:41 PM, Sebastian Herbszt wrote:
H. Peter Anvin wrote:
On 10/11/2010 01:30 PM, Anthony Liguori wrote:
On 10/11/2010 02:59 PM, Gleb Natapov wrote:
No boot rom should do that. extboot wreaks havoc when it is used.
And since virtio is now supported by bios there is no reason
On 10/12/2010 01:01 AM, Gleb Natapov wrote:
On Mon, Oct 11, 2010 at 02:15:26PM -0700, H. Peter Anvin wrote:
I don't disagree.
I think the best thing to do is to let SeaBIOS create a boot order table
that contains descriptive information and then advertise that to QEMU.
QEMU can then try
On real hardware it is shared between BIOS and the OS, actually.
Gleb Natapov g...@redhat.com wrote:
On Tue, Oct 12, 2010 at 09:33:16AM -0700, H. Peter Anvin wrote:
On 10/12/2010 01:01 AM, Gleb Natapov wrote:
On Mon, Oct 11, 2010 at 02:15:26PM -0700, H. Peter Anvin wrote:
I don't disagree
On 10/12/2010 10:41 AM, Gleb Natapov wrote:
On Tue, Oct 12, 2010 at 10:35:51AM -0700, H. Peter Anvin wrote:
On real hardware it is shared between BIOS and the OS, actually.
Guest OS can write in qemu CMOS too. But what is it useful for? Most of
its content is not standard AFAIK
On 10/12/2010 12:06 PM, Gleb Natapov wrote:
This is true to some extent -- there is some standard content, and some
further can be described via ACPI tables. However, my point was mostly
that it is an existing model for nonvolatile storage which also works on
hardware (and is vastly simpler
On 10/13/2010 12:17 PM, H. Peter Anvin wrote:
The ACPI specification recognizes three interfaces as standard: PC/AT
(64 bytes, even though 128 bytes is available on a lot of platforms),
PIIX4 (256 bytes), and Dallas Semiconductor (256 bytes or more). The
interface for the latter isn't well
On 10/13/2010 01:00 PM, H. Peter Anvin wrote:
On 10/13/2010 12:17 PM, H. Peter Anvin wrote:
The ACPI specification recognizes three interfaces as standard: PC/AT
(64 bytes, even though 128 bytes is available on a lot of platforms),
PIIX4 (256 bytes), and Dallas Semiconductor (256 bytes
will never work.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 10/14/2010 05:57 AM, Anthony Liguori wrote:
I've always been sceptical of this. When physical systems have a large
number of NICs, it's via multiple functions, not a bunch of PCI bridges.
Actually a lot of multiport PCI cards are in fact single or dual NICs
behind PCI bridges.
On 10/28/2010 1:01 AM, Gerd Hoffmann wrote:
On 10/27/10 19:13, H. Peter Anvin wrote:
On 10/27/2010 9:04 AM, Gerd Hoffmann wrote:
This brings a usb audio device to qemu. Output only, fixed at
16bit stereo @ 48 Hz. Based on a patch from
H. Peter Anvinh...@linux.intel.com
Please don't
On 10/28/2010 1:01 AM, Gerd Hoffmann wrote:
On 10/27/10 19:13, H. Peter Anvin wrote:
On 10/27/2010 9:04 AM, Gerd Hoffmann wrote:
This brings a usb audio device to qemu. Output only, fixed at
16bit stereo @ 48 Hz. Based on a patch from
H. Peter Anvinh...@linux.intel.com
Please don't
On 10/28/2010 1:01 AM, Gerd Hoffmann wrote:
On 10/27/10 19:13, H. Peter Anvin wrote:
On 10/27/2010 9:04 AM, Gerd Hoffmann wrote:
This brings a usb audio device to qemu. Output only, fixed at
16bit stereo @ 48 Hz. Based on a patch from
H. Peter Anvinh...@linux.intel.com
Please don't
On 08/24/2010 12:15 PM, Vagrant Cascadian wrote:
it seems versions of pxelinux 4.00 and later hangs qemu (0.12.x, 0.13.x) when
network booting using etherboot or gPXE and qemu's kvm support is enabled.
pxelinux 3.86 and earlier do not appear to trigger the problem. i also didn't
experience
the number of samples actually consumed
to construct the functional sample rate on the USB clock, as long as
that information can be acquired.
Not-yet-signed-off-by: H. Peter Anvin h...@linux.intel.com
---
Makefile.objs |1 +
arch_init.c| 24 ++-
configure |6 +-
create_config
On 09/06/2010 05:45 AM, Anthony Liguori wrote:
Before inventing yet another image format, you certainly have checked
the existing ones.
Obviously, yes.
Here are the issues:
cow.c: it's cow of an otherwise sparse file. An important reason for
implementing a format is the ability to
On 09/10/2010 05:28 PM, malc wrote:
On Fri, 10 Sep 2010, H. Peter Anvin wrote:
I discovered that none of the audio device models supported by current
Qemu/KVM appear to be supported out of the box on Win7 64 bit (AC97
works fine on 32 bit). The most logical ways to fix that would be to
add
On 09/10/2010 06:08 PM, H. Peter Anvin wrote:
Any remotely recent stock distro should have support for it. I say
should, because I haven't actually tested it with a Linux guest yet.
I'll try to do that later; I have to leave now.
Just tested it on a stock Fedora 13 64 bit VM; it behaves
On 09/10/2010 07:47 PM, H. Peter Anvin wrote:
On 09/10/2010 06:08 PM, H. Peter Anvin wrote:
Any remotely recent stock distro should have support for it. I say
should, because I haven't actually tested it with a Linux guest yet.
I'll try to do that later; I have to leave now.
Just tested
I meant just take the Fedora 13 DVD and install it onto a virtual hard disk.
More later when I'm at a real computer.
malc av1...@comtv.ru wrote:
On Fri, 10 Sep 2010, H. Peter Anvin wrote:
On 09/10/2010 07:47 PM, H. Peter Anvin wrote:
On 09/10/2010 06:08 PM, H. Peter Anvin wrote:
Any
It would certainly be a worthwhile project.
Alexander Graf ag...@suse.de wrote:
On 11.09.2010, at 03:08, H. Peter Anvin wrote:
[snip]
I know. Someone else is welcome to do that... since it would require
knowing both the VirtualBox and the Qemu sound subsystem interfaces and
in what ways
On 09/11/2010 12:41 AM, Stefan Hajnoczi wrote:
On Fri, Sep 10, 2010 at 10:47 PM, H. Peter Anvin h...@linux.intel.com wrote:
diff --git a/hw/usb-audio.c b/hw/usb-audio.c
new file mode 100644
index 000..d4cf488
--- /dev/null
+++ b/hw/usb-audio.c
@@ -0,0 +1,702 @@
+/*
+ * QEMU USB Net
On 09/13/2010 01:53 PM, Amos Kong wrote:
# patch -p1 /tmp/usb-audio.patch
# ./configure
...
...
preadv supportyes
fdatasync yes
uuid support no
vhost-net support no
Trace backend nop
Trace output file trace-pid
./configure: 2276: Bad substitution
What shell is
On 09/13/2010 01:53 PM, Amos Kong wrote:
# patch -p1 /tmp/usb-audio.patch
# ./configure
...
...
preadv supportyes
fdatasync yes
uuid support no
vhost-net support no
Trace backend nop
Trace output file trace-pid
./configure: 2276: Bad substitution
diff --git
is normal?
Yes, all of that is normal. I talked to malc earlier today, and I think
I have a pretty good idea for how to deal with the rate-matching issues;
I'm going to try to write it up tomorrow.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak
On 09/17/2010 06:11 AM, Kevin O'Connor wrote:
On Fri, Sep 17, 2010 at 07:53:12AM -0500, Anthony Liguori wrote:
On 09/16/2010 08:47 PM, Kevin O'Connor wrote:
On Wed, Sep 15, 2010 at 07:15:28PM +0200, Andrea Arcangeli wrote:
This uses a new cmos port at 0x5e that shall read zero to be backwards
From: H. Peter Anvin h...@zytor.com
Add generic support for debugging consoles (simple I/O ports which
when written to cause debugging output to be written to a target.)
The current implementation matches Bochs' port 0xe9, allowing the same
debugging code to be used for both Bochs and Qemu
On 12/29/2009 01:39 PM, H. Peter Anvin wrote:
8 files changed, 187 insertions(+), 1 deletions(-)
Sorry everyone, re-sent an old version by mistake. Correctly updated
patch will follow.
-hpa
until we are parsing the
other console-like devices.
Signed-off-by: H. Peter Anvin h...@linux.intel.com
---
Makefile.target |2 +-
hw/debugcon.c | 107 +++
qemu-options.hx | 11 ++
vl.c| 23
4 files changed
On 12/30/2009 08:49 AM, Kevin O'Connor wrote:
On Tue, Dec 29, 2009 at 01:51:36PM -0800, H. Peter Anvin wrote:
Add generic support for debugging consoles (simple I/O ports which
when written to cause debugging output to be written to a target.)
The current implementation matches Bochs' port
unusual choice of ports... port 0x80 is the
normal port for BIOSes to display debugging information on.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 01/02/2010 09:53 AM, Kevin O'Connor wrote:
On Fri, Jan 01, 2010 at 07:02:59PM -0800, H. Peter Anvin wrote:
On 12/30/2009 08:49 AM, Kevin O'Connor wrote:
SeaBIOS writes debugging info to port 0x0402. Unfortunately, qemu has
to be recompiled in order to display this info. Will your patch
with the debugging port, simply
because it has none -- the entire interface is a single, stateless,
write-only port.
Most of the code was cribbed from the serial port driver.
Signed-off-by: H. Peter Anvin h...@linux.intel.com
---
Makefile.target |2 +-
hw/debugcon.c | 189
Sebastian Herbszt wrote:
H. Peter Anvin wrote:
Add generic support for debugging consoles (simple I/O ports which
when written to cause debugging output to be written to a target.)
The current implementation matches Bochs' port 0xe9, allowing the same
debugging code to be used for both Bochs
On 11/23/2009 02:52 AM, Gerd Hoffmann wrote:
All not needed. Simply registering as qdev device is enougth. You can
then add a debug port like this, without adding new cmd line options:
-chardev vc,id=debug -device isa-debugcon,chardev=debug
Adding a second one on a non-default port
On 11/23/2009 12:11 PM, H. Peter Anvin wrote:
On 11/23/2009 02:52 AM, Gerd Hoffmann wrote:
All not needed. Simply registering as qdev device is enougth. You can
then add a debug port like this, without adding new cmd line options:
-chardev vc,id=debug -device isa-debugcon,chardev=debug
Gerd Hoffmann wrote:
You can stick it into a config file[1] like this:
[chardev debuglog]
backend = file
path = /path/to/debug.log
[device]
driver = isa-debugcon
chardev = debuglog
Then use qemu -readconfig $file.
Great... at least in my opinion, one of the things that makes Qemu
On 11/25/2009 02:21 PM, Gerd Hoffmann wrote:
You can happily mixup things as you like. Use pure command line. Use
pure config file (well, at least is that the plan, it doesn't fully work
yet). Mix cmd line switches and config file. Reading multiple config
files works just fine too, so
On 11/25/2009 02:26 PM, H. Peter Anvin wrote:
As such, I think there is still a place for the simple command line
options like -hda, -serial and my proposed -debugcon, in addition
to the full-featured connect-anything options and configuration files.
That's all.
I guess one question
From: H. Peter Anvin h...@zytor.com
Add generic support for debugging consoles (simple I/O ports which
when written to cause debugging output to be written to a target.)
The current implementation matches Bochs' port 0xe9, allowing the same
debugging code to be used for both Bochs and Qemu
for
-chardev stdio,id=debugcon -device isa-debugcon,chardev=debugcon) --
this dramatically reduced the complexity while keeping the same level
of user friendliness.
Signed-off-by: H. Peter Anvin h...@linux.intel.com
---
Makefile.target |2 +-
hw/debugcon.c | 107
for
-chardev stdio,id=debugcon -device isa-debugcon,chardev=debugcon) --
this dramatically reduced the complexity while keeping the same level
of user friendliness.
v4: spaces, not tabs.
Signed-off-by: H. Peter Anvin h...@linux.intel.com
---
Makefile.target |2 +-
hw/debugcon.c | 107
tree doesn't compile for me, so I can't verify it is
actually OK.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
From e76a33ee6516e92f1e7223d590c6870c1ec689c9 Mon Sep 17 00:00:00 2001
From: H. Peter Anvin h...@zytor.com
Date
Jorge Lucángeli Obes wrote:
The '#!' trick works nice with scripts, but I don't see it playing
very well with images. ¿Comments? ¿Pointers?
Well, you can make it work with a header (you just have to pad it out to
a fixed length or use a variable-offset format), but binfmt_misc might
be a
I saw the following patch in the Qemu source:
Index: rombios.c
===
RCS file: /cvsroot/bochs/bochs/bios/rombios.c,v
retrieving revision 1.174
diff -u -w -r1.174 rombios.c
--- rombios.c 17 Oct 2006 16:48:05 - 1.174
+++
Blue Swirl wrote:
On 2/9/08, Rob Landley [EMAIL PROTECTED] wrote:
Here's a patch Peter Anvin wrote so the serial I/O doesn't flood the kernel.
The patch looks OK, but the throttling should benefit all devices, as
discussed here:
Blue Swirl wrote:
If you look at the patch, there are no timing dependencies; the only
parameter is the depth of the virtual queue. The exhaustion is
completely controlled by target OS access patterns.
Thanks, this clarified the difference. But I'll rephrase my original comment:
The patch
: /dev/random in the guest
will behave like (a very expensive version of) /dev/urandom from
a cryptographic point of view.
The right interface to the host kernel, therefore, is /dev/random.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak
protocol.
Anyway, this is on my list for 1.3. The series just needs some light
dusting before resubmission.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
Right, obviously. However, under no circumstances should /dev/urandom be used!
Amit Shah amit.s...@redhat.com wrote:
On (Sun) 16 Sep 2012 [13:42:46], H. Peter Anvin wrote:
On 06/19/2012 11:59 PM, Amit Shah wrote:
Hello,
Here's the 3rd iteration of the virtio-rng device. This update just
From: H. Peter Anvin h...@linux.intel.com
This patch implements Supervisor Mode Execution Prevention (SMEP) and
Supervisor Mode Access Prevention (SMAP) for x86. The purpose of the
patch, obviously, is to help kernel developers debug the support for
those features.
A fair bit of the code
On 09/26/2012 12:50 PM, Anthony Liguori wrote:
The patch looks good except for these two chunks. This would break live
migration from a new QEMU to an old one because CPUs are currently not
versioned.
If you just remove these two chunks, the patch can be applied and you
can still test
From: H. Peter Anvin h...@linux.intel.com
This patch implements Supervisor Mode Execution Prevention (SMEP) and
Supervisor Mode Access Prevention (SMAP) for x86. The purpose of the
patch, obviously, is to help kernel developers debug the support for
those features.
A fair bit of the code
On 09/26/2012 01:32 PM, Igor Mammedov wrote:
+
+static void x86_cpuid_get_feature(Object *obj, Visitor *v, void *opaque,
+ const char *name, Error **errp)
+{
+X86CPU *cpu = X86_CPU(obj);
+CPUX86State *env = cpu-env;
+bool value = true;
+
On 08/16/2012 11:53 AM, Alan Cox wrote:
Yes, if I remove the break statement (introduced by this commit), it works
fine.
What version of qemu is this - do we have qemu bug here I wonder.
Also, is it 32 or 64 bits?
-hpa
be an option to don't start the guest until X
bytes of entropy have been gathered.
Overall, I want to emphasize that we don't want to try solve generic
problems in virtualization space... resource constraints on /dev/random
is a generic host OS issue for example.
-hpa
--
H. Peter
PRNGs don't create entropy. Period.
The guest will run its own PRNG.
Anthony Liguori aligu...@us.ibm.com wrote:
H. Peter Anvin h...@zytor.com writes:
On 10/26/2012 08:42 AM, Anthony Liguori wrote:
Is /dev/random even appropriate to feed rngd?
rngd needs _a lot_ of entropy to even start
with an outline for what we can do to improve the current
situation. It is challenging to deal with the patanoia crowd at the same time.
Paolo Bonzini pbonz...@redhat.com wrote:
Il 26/10/2012 18:09, H. Peter Anvin ha scritto:
a) it means that the guest *has* to run rngd or a similar engine
That statement is pretty toxic... I wonder where it came from. It is at best
horribly misleading and actively encourages dangerous behaviours even for the
cases where it isn't actively wrong.
Paolo Bonzini pbonz...@redhat.com wrote:
Il 26/10/2012 21:07, H. Peter Anvin ha scritto
On 10/26/2012 12:51 PM, Paolo Bonzini wrote:
Il 26/10/2012 21:07, H. Peter Anvin ha scritto:
This is surreal. Output from /dev/hwrng turns into output for
/dev/random... it us guaranteed worse; period, end of story.
Isn't that exactly what happens in bare-metal? hwrng - rngd - random
the PRNG in host space.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
/random, is all
I care about at this time.
There is always time to change defaults to something better.
Your logic are roughly on the level with the people who caused the
Debian bug. You are proposing something utterly reckless. Sorry,
please stop.
-hpa
--
H. Peter Anvin, Intel
On 10/29/2012 01:45 AM, Paolo Bonzini wrote:
Il 26/10/2012 22:29, H. Peter Anvin ha scritto:
This is surreal. Output from /dev/hwrng turns into output for /dev/random...
it us guaranteed worse; period, end of story.
Isn't that exactly what happens in bare-metal? hwrng - rngd - random
On 10/30/2012 02:05 AM, Paolo Bonzini wrote:
Either you're not reading what I wrote, or you're confusing me with
someone else.
My apologies, you are indeed correct. I misinterpreted your emails,
probably because I got you confused with someone else.
I *never* mentioned passing /dev/urandom,
. If
RDRAND is available in the guest it should be used directly if rngd is
new enough, but since virtio-rng has been in the kernel since 2008 there
still might be some guests which could use such an implementation
without having been RDRAND-enabled.
-hpa
--
H. Peter Anvin, Intel Open Source
in newer CPUs to correct this.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
MOVBE. This is
needed when booting 3.8 and later linux kernels built with the MATOM
target because we require MOVBE in order to boot properly now.
Cc: H. Peter Anvin h...@zytor.com
Cc: Richard Henderson r...@twiddle.net
Signed-off-by: Borislav Petkov b...@suse.de
---
Right, so I
On 02/14/2013 12:41 PM, Laszlo Ersek wrote:
). cpu_reset() [target-i386/helper.c] sets CS:IP to f000:fff0, which is
the exact address of... reset_vector() in SeaBIOS.
This would be a bug, but it isn't quite true.
If you look at x86_cpu_reset() you will note that it sets the code
segment
-Kbyte range.
That is presumably a 286 compatibility hack -- the 286 had 24 address
lines. I doubt anyone gives a hoot about it, and neither EDK2 nor
SeaBIOS should care.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
From: H. Peter Anvin h...@zytor.com
If we touch control registers that don't exist, either read or write,
raise the #UD exception (undefined opcode).
This is useful for testing booting on old CPUs.
CR4 is assumed to exist if and only if there are CPU features other
than the FPU defined
From: H. Peter Anvin h...@zytor.com
There is no standard method for storing timezone information
associated with the classic PC/AT RTC, however, there are standard
methods in ACPI (Time and Alarm Device) and EFI (GetTime/SetTime) for
getting this information.
Since these are abstract methods
From: H. Peter Anvin h...@zytor.com
Add models for 486SX, and pre-CPUID versions of the 486 (DX SX).
Change the model number for the standard 486DX to a model which
actually had CPUID.
Note: these models are fairly vestigial, for example most of the FPU
operations still work; only F*ST[CS]W
that version of the patch, with a suitable comment.
Right... the soft reset described above is really INIT, which isn't
even a reset in modern CPUs (it couldn't be, it has to preserve caches)
but more of a special interrupt. It is also used during multiprocessor
init.
-hpa
--
H. Peter
On 02/28/2013 04:36 PM, Eric Blake wrote:
Stefan Berger and I discovered on IRC that virtio-rng is unable to
support fd passing. We attempted:
qemu-system-x86_64 ... -add-fd
set=4,fd=34,opaque=RDONLY:/dev/urandom
-object
On 02/28/2013 04:24 AM, M. Mohan Kumar wrote:
By default 9p.u is used, you can override by that
mount -t 9p -otrans=virtio,version=9p2000.L tag /mnt
Shouldn't we change that default?
-hpa
The guest kernel already provides the PRNG itself. We have been over this...
Stefan Berger stef...@linux.vnet.ibm.com wrote:
On 03/01/2013 02:37 PM, H. Peter Anvin wrote:
On 02/28/2013 04:36 PM, Eric Blake wrote:
Stefan Berger and I discovered on IRC that virtio-rng is unable to
support fd
in the
guest!) and it does make sense for a very thin host.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
Low priority ping on this patchset...?
-hpa
On 03/25/2013 02:05 AM, Paolo Bonzini wrote:
Interesting, do you have SeaBIOS and/or OVMF patches for this?
Not at this point.
-hpa
On 03/25/2013 08:15 AM, Igor Mammedov wrote:
Such changes have been rejected in the past (e.g., n270 Atom).
I personally wouldn't object to 486 changes, but I guess it should
rather be handled via Igor's CPU static properties that I have in my
review queue: The .model value would be set to 8
On 03/25/2013 12:05 PM, Eduardo Habkost wrote:
On Mon, Mar 25, 2013 at 11:44:30AM -0700, H. Peter Anvin wrote:
On 03/25/2013 08:15 AM, Igor Mammedov wrote:
Such changes have been rejected in the past (e.g., n270 Atom).
I personally wouldn't object to 486 changes, but I guess it should
rather
Now, all this said... if the only objection is the change of model
number for 486 then I suggest just dropping that.
-hpa
On 03/25/2013 01:56 PM, Eduardo Habkost wrote:
It needs to be possible to fix bugs
It is possible to fix them today: just write a compat function or add a
global variable that is handled by cpu_x86_init(), and call it from the
pc-1.3 machine-type init function. See
On 03/28/2013 12:15 PM, Aurelien Jarno wrote:
This really looks like Linux kernel specific. I haven't been able to
test on a real machine, but the documentation I have found suggest that
without and x87 FPU, the FPU instructions are simply ignored. The common
way to detect an FPU is
On 03/28/2013 12:15 PM, Aurelien Jarno wrote:
This really looks like Linux kernel specific. I haven't been able to
test on a real machine, but the documentation I have found suggest that
without and x87 FPU, the FPU instructions are simply ignored. The common
way to detect an FPU is
Qemu is absolutely horrid at modeling corner cases.
Rob Landley r...@landley.net wrote:
On 03/28/2013 03:12:11 PM, H. Peter Anvin wrote:
On 03/28/2013 12:15 PM, Aurelien Jarno wrote:
This really looks like Linux kernel specific. I haven't been able
to
test on a real machine
1 - 100 of 136 matches
Mail list logo
