On February 2, 2023 7:17:01 AM PST, James Bottomley wrote:
>On Thu, 2023-02-02 at 07:03 -0800, H. Peter Anvin wrote:
>[...]
>> NAK. We need to fix the actual problem of the kernel stomping on
>> memory it shouldn't, not paper around it.
>
>This is a first boot situati
On February 2, 2023 7:17:01 AM PST, James Bottomley wrote:
>On Thu, 2023-02-02 at 07:03 -0800, H. Peter Anvin wrote:
>[...]
>> NAK. We need to fix the actual problem of the kernel stomping on
>> memory it shouldn't, not paper around it.
>
>This is a first boot situati
On February 2, 2023 7:17:01 AM PST, James Bottomley wrote:
>On Thu, 2023-02-02 at 07:03 -0800, H. Peter Anvin wrote:
>[...]
>> NAK. We need to fix the actual problem of the kernel stomping on
>> memory it shouldn't, not paper around it.
>
>This is a first boot situati
On February 2, 2023 6:38:12 AM PST, James Bottomley wrote:
>On Wed, 2023-02-01 at 15:48 -0500, Jason A. Donenfeld wrote:
>[...]
>> But it sounds like you might now have a concrete suggestion on
>> something even better. I'm CCing hpa, as this is his wheelhouse, and
>> maybe you two can divise the
On January 31, 2023 1:22:43 PM PST, "Jason A. Donenfeld"
wrote:
>On Tue, Jan 31, 2023, 15:55 H. Peter Anvin wrote:
>
>> On January 30, 2023 12:19:14 PM PST, "Michael S. Tsirkin"
>> wrote:
>> >From: "Jason A. Donenfeld"
>> >
&g
ttle semantics would have to
>be changed around, incurring more complexity. In contrast, using cmdline
>is simple and doesn't interfere with anything.
>
>The microvm machine has a gross hack where it fiddles with fw_cfg data
>after the fact. So this hack is updated to account for th
On 12/31/22 20:55, Mika Penttilä wrote:
If decompression does clobber the data, then we *also* need to figure
out why that is. There are basically three possibilities:
1. If physical KASLR is NOT used:
a. The boot loader doesn't honor the kernel safe area properly;
b. Somewhere in
On 12/31/22 10:22, Jason A. Donenfeld wrote:
On Sat, Dec 31, 2022 at 03:24:32PM +0100, Borislav Petkov wrote:
On Sat, Dec 31, 2022 at 02:51:28PM +0100, Jason A. Donenfeld wrote:
That failure is unrelated to the ident mapping issue Peter and
I discussed. The original failure is described in t
On 12/31/22 19:21, H. Peter Anvin wrote:
Alternatively, setup_data could be relocated, the boot param protocol
could be bumped, and then QEMU could conditionalized it's use of
setup_data based on that protocol version. That'd work, but seems a bit
more involved.
I think this i
On 12/31/22 11:00, Borislav Petkov wrote:
On Sat, Dec 31, 2022 at 07:22:47PM +0100, Jason A. Donenfeld wrote:
So with that understanding confirmed, I'm confused at your surprise that
hpa's unrelated fix to the different issue didn't fix this issue.
No surprise there - I used a qemu variant
On 12/30/22 17:06, H. Peter Anvin wrote
TThe 62 MB limit mentioned in boot.rst is unrelated, and only applies to
very, very old kernels that used INT 15h, AH=88h to probe memory.
I am 88% sure this was fixed long before setup_data was created, as it
was created originally to carry e820
On 12/30/22 14:10, Jason A. Donenfeld wrote:
On Fri, Dec 30, 2022 at 01:58:39PM -0800, H. Peter Anvin wrote:
See the other thread fork. They have identified the problem already.
Not sure I follow. Is there another thread where somebody worked out why
this 62meg limit was happening?
Note
On December 30, 2022 11:54:11 AM PST, Borislav Petkov wrote:
>On Fri, Dec 30, 2022 at 06:07:24PM +0100, Jason A. Donenfeld wrote:
>> Look closer at the boot process. The compressed image is initially at
>> 0x10, but it gets relocated to a safer area at the end of
>> startup_64:
>
>That is the
On December 30, 2022 7:59:30 AM PST, "Jason A. Donenfeld"
wrote:
>Hi,
>
>On Wed, Dec 28, 2022 at 11:31:34PM -0800, H. Peter Anvin wrote:
>> On December 28, 2022 6:31:07 PM PST, "Jason A. Donenfeld"
>> wrote:
>> >Hi,
>> >
>> >
On December 28, 2022 6:31:07 PM PST, "Jason A. Donenfeld"
wrote:
>Hi,
>
>Read this message in a fixed width text editor with a lot of columns.
>
>On Wed, Dec 28, 2022 at 03:58:12PM -0800, H. Peter Anvin wrote:
>> Glad you asked.
>>
>> So the kernel loa
On December 28, 2022 6:31:07 PM PST, "Jason A. Donenfeld"
wrote:
>Hi,
>
>Read this message in a fixed width text editor with a lot of columns.
>
>On Wed, Dec 28, 2022 at 03:58:12PM -0800, H. Peter Anvin wrote:
>> Glad you asked.
>>
>> So the kernel loa
On 12/28/22 15:58, H. Peter Anvin wrote:
On December 28, 2022 8:57:54 AM PST, "Jason A. Donenfeld"
wrote:
HELLO H. PETER ANVIN,
E
L
L
O
On Wed, Dec 28, 2022 at 05:30:30PM +0100, Jason A. Donenfeld wrote:
Fix looks good, glad you figured out the problem.
I mean, kind of. The sol
On December 28, 2022 8:57:54 AM PST, "Jason A. Donenfeld"
wrote:
>HELLO H. PETER ANVIN,
>E
>L
>L
>O
>
>On Wed, Dec 28, 2022 at 05:30:30PM +0100, Jason A. Donenfeld wrote:
>> > Fix looks good, glad you figured out the problem.
>>
>> I mean, kin
On 6/5/19 12:55 PM, H. Peter Anvin wrote:
> Hi,
>
> I am writing some code I'm hoping will be able to make it into Qemu, but I
> can't seem to find what the baseline portability requirements are. I'm
> specifically wondering about newer POSIX features like openat(
Hi,
I am writing some code I'm hoping will be able to make it into Qemu, but I
can't seem to find what the baseline portability requirements are. I'm
specifically wondering about newer POSIX features like openat(), which seems
to be used in the 9p filesystem and nowhere else, and what version of
On 11/11/18 10:19 PM, Ingo Molnar wrote:
>
>> In part as a result of this exchange I have spent some time thinking
>> about the boot protocol and its dependencies, and there is, in fact, a
>> much more serious problem that needs to be addressed: it is not
>> currently possible in a forward-comp
On 11/11/18 10:19 PM, Ingo Molnar wrote:
>
> I might be a bit dense early in the morning, but could you elaborate?
> What do you mean by mapping all data areas?
>
Heh. I need to pack for LPC and get some sleep before my flight lest I'll be
denser than depleted uranium; I'll write an explanation
On 11/11/18 8:56 PM, Ingo Molnar wrote:
>
>> Also note that the ext_ramdisk_image and ext_ramdisk_size are part of
>> struct boot_params as opposed to struct setup_header, which means that
>> they are not supported when entering via the 16-bit BIOS entry point,
>> and I am willing to bet that ther
On 11/9/18 5:40 AM, Li Zhijian wrote:
> Just noticed that there is a field xloadflags at recent protocol
> 60 Protocol 2.12: (Kernel 3.8) Added the xloadflags field and
> extension fields
> 61 to struct boot_params for loading bzImage and ramdisk
> 62 above 4G
On 11/21/16 11:45, Hervé Poussineau wrote:
> The blocksize option is defined in RFC 1783.
> We now support block sizes between 1 and 1432 bytes, instead of 512 only.
It ought to be 1476: Ethernet MTU = 1500, minus a minimum of 20 bytes
for an IPv4 header and 4 for a TFTP header.
Some bootloaders
On April 18, 2016 4:26:24 AM PDT, "Daniel P. Berrange"
wrote:
>On Mon, Apr 18, 2016 at 01:07:40PM +0200, Hubert Kario wrote:
>> On Monday 18 April 2016 02:46:19 H. Peter Anvin wrote:
>> > Another thing that really needs to be addressed, but is a separate
>> &
On April 18, 2016 2:28:42 AM PDT, "Daniel P. Berrange"
wrote:
>On Fri, Apr 15, 2016 at 08:56:59AM -0700, H. Peter Anvin wrote:
>> On April 15, 2016 3:41:34 AM PDT, Cole Robinson
>wrote:
>> >Libvirt currently rejects using host /dev/urandom as an input source
>&
On 04/16/16 01:31, Paolo Bonzini wrote:
>
> Right, but there's always the point about people that use heterogeneous
> hosts and cannot pass rdrand/rdseed to the guest. For these, we should
> add a QEMU driver that uses rdrand/rdseed, and thus decouples virtio-rng
> from the host /dev/* completely
On 04/16/16 01:31, Paolo Bonzini wrote:
>
> Right, but there's always the point about people that use heterogeneous
> hosts and cannot pass rdrand/rdseed to the guest. For these, we should
> add a QEMU driver that uses rdrand/rdseed, and thus decouples virtio-rng
> from the host /dev/* completely
On April 15, 2016 9:10:44 AM PDT, Hubert Kario wrote:
>On Friday 15 April 2016 09:47:51 Eric Blake wrote:
>> On 04/15/2016 04:41 AM, Cole Robinson wrote:
>> > Libvirt currently rejects using host /dev/urandom as an input
>source
>> > for a virtio-rng device. The only accepted sources are /dev/rand
On April 15, 2016 9:10:44 AM PDT, Hubert Kario wrote:
>On Friday 15 April 2016 09:47:51 Eric Blake wrote:
>> On 04/15/2016 04:41 AM, Cole Robinson wrote:
>> > Libvirt currently rejects using host /dev/urandom as an input
>source
>> > for a virtio-rng device. The only accepted sources are /dev/rand
On April 15, 2016 3:41:34 AM PDT, Cole Robinson wrote:
>Libvirt currently rejects using host /dev/urandom as an input source
>for a
>virtio-rng device. The only accepted sources are /dev/random and
>/dev/hwrng.
>This is the result of discussions on qemu-devel around when the feature
>was
>first ad
ix xsave cpuid exposing bug
>>
>> EBX of cpuid(0xD, 0) is dynamic per XCR0 features enable/disable.
>> Bit 63 of XCR0 is reserved for future expansion.
>>
>> Signed-off-by: Liu Jinsong
>
> Peter, can I have your acked-by on this?
>
Yes.
Acked-by: H. Peter Anvin
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 disable_kvm
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.
On 12/06/2013 04:23 PM, Ren, Qiaowei wrote:
>>>
>>> We need to either disable these features in lazy mode, or we need to
>>> force eager mode if these features are to be supported. The problem
>>> with the latter is that it means forcing eager mode regardless of if
>>> anything actually *uses* the
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
>
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 M
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 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 ar
No... we always ask for cpufeature.h patches separately because they sometimes
cause conflicts between branches.
Borislav Petkov wrote:
>On Sat, Dec 07, 2013 at 02:52:55AM +0800, Qiaowei Ren wrote:
>>
>> Signed-off-by: Qiaowei Ren
>> Signed-off-by: Xudong Hao
>> Signed-off-by: Liu Jinsong
>>
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
>> Date: Fri, 29 Nov 2013 01:27:00 +0800
>> Subject: [PATCH 1/4] X86: Intel MPX definiation
>>
>> Signed-off-b
On 08/28/2013 10:35 AM, Anthony Liguori wrote:
> Yes, it was originally designed with the 16TB limit in mind.
>
> PCI doesn't support 64-bit PIO operations so it would have required a
> high/low register and additional magic.
>
s/PCI/x86/
"Additional magic" is needed only if atomic changes are
Only on a real 286. At least since 486 the legacy switch has been INIT, not
RESET.
Alexander Graf wrote:
>
>
>Am 14.06.2013 um 08:56 schrieb Christian Borntraeger
>:
>
>> On 13/06/13 13:56, Anthony Liguori wrote:
>>> Markus Armbruster writes:
>>>
Peter Lieven writes:
> On 13.
On 03/29/2013 09:01 AM, Christophe Lyon wrote:
> Add a space at end of line when there is no filename to print, to
> conform to linux kernel format.
>
> Signed-off-by: Christophe Lyon
> ---
> linux-user/syscall.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/linux-
Qemu is absolutely horrid at modeling corner cases.
Rob Landley 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
&
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 ther
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 ther
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 disable_kvm
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 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 w
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
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
Low priority ping on this patchset...?
-hpa
ographically sound (since it presents itself as /dev/hwrng 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.
The guest kernel already provides the PRNG itself. We have been over this...
Stefan Berger 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
>>&
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
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 rng-random,id=rng0,fil
table 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 Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
From: "H. Peter Anvin"
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[
From: "H. Peter Anvin"
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, it
From: "H. Peter Anvin"
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 (typ
bytes minus 256-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.
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
QEMU speak) supports 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"
>> Cc: Richard Henderson
>> Signed-off-by: Borislav Petko
here is a new RDSEED instruction 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.
s would be the one to use. 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.
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
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 -
t's /dev/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 Anvi
ng a completely
unnecessary hypercall to run 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.
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
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 wrote:
>Il 26/10/2012 21:07, H. Peter Anvin ha scritto:
>> This is su
and we came up 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 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
PRNGs don't "create entropy." Period.
The guest will run its own PRNG.
Anthony Liguori wrote:
>"H. Peter Anvin" writes:
>
>> On 10/26/2012 08:42 AM, Anthony Liguori wrote:
>>>>
>>>> Is /dev/random even appropriate to feed rngd?
nts on /dev/random
is a generic host OS issue for example.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
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 = t
From: "H. Peter Anvin"
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 relates to th
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 t
From: "H. Peter Anvin"
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 relates to th
Right, obviously. However, under no circumstances should /dev/urandom be used!
Amit Shah 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
ia a sane fairness daemon which doesn't need a
complicated 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.
o put it differently: /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 Inte
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
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 Anvin
Please don't apply this. This
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 Anvin
Please don't apply this. This
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 Anvin
Please don't apply this. This
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/14/2010 09:18 AM, Alon Levy wrote:
>
> Can you elaborate?
>
The quality of rate information is too low, and the delays in the system
are too large to enable consistent convergence.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don&#
lt really is: it doesn't work, and it probably 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/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
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
>
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
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
On real hardware it is shared between BIOS and the OS, actually.
"Gleb Natapov" 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 wr
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
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 sinc
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 hardw
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 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 b
1 - 100 of 140 matches
Mail list logo
