qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC] acpi: add reset register to fadt


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH RFC] acpi: add reset register to fadt
Date: Wed, 8 Feb 2017 01:52:36 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

On 02/07/17 22:02, Phil Dennis-Jordan wrote:
> On 7 February 2017 at 20:54, Laszlo Ersek <address@hidden> wrote:

>> I filed <https://bugzilla.tianocore.org/show_bug.cgi?id=368>.
> 
> That looks nice and thorough.
> 
>>> Your EDK2 patch
>>
>> For the record:
>> [1] https://lists.01.org/pipermail/edk2-devel/2017-February/007072.html
>>
>>> fixes the problem with values OVMF writes to
>>> DSDT/X_DSDT, but the issue of it refusing Qemu's linker commands for
>>> those two still needs to be solved so that SeaBIOS can boot a wide
>>> range of OSes.
>>>
>>> I'd be happy to give writing the memoising patch a go myself if that
>>> helps. Looks like setting up an ORDERED_COLLECTION during phase 2
>>> might be the simplest solution?
>>
>> Thanks for the offer. :)
>>
>> * If you'd like to help me with my load and reach a good "development
>>   throughput", then I prefer to write the patch myself. On this
>>   *specific* occasion, I think it will be faster.
>>
>>   I intend to send an OVMF series this week that addresses both
>>   TianoCore#368 (see above) and TianoCore#359 too (mentioned earlier).
>>   Both are for OvmfPkg/AcpiPlatformDxe, and it makes sense to round
>>   them up.
>>
>>   I plan to CC the QEMU stakeholders as appropriate. Your feedback
>>   would be greatly appreciated; the same way as [1] is very helpful
>>   (thanks again for it!)
>>
>> * If your main interest is rather to get into OVMF development, then I
>>   positively welcome that, and encourage you to send the patch.
>>   Completing the patch will likely take longer (the edk2 coding style
>>   is... arcane... and your reviewer is somewhat pedantic :)), but if
>>   you plan to get into OVMF development, then it's worth both our times.
>>
>> (The above should not be misunderstood as "Laszlo doesn't value one-off
>> contributions" -- it really depends on feature size and area. Hence the
>> emphasis on "specific" above.)
>>
>> Your call :) If possible, please let me know it tomorrow.
> 
> I actually ended up writing said pointer memoisation patch yesterday,
> and it appears to work fine in initial tests. I still need to fully
> work my way through the edk2 coding and contribution guidelines, so
> I'll need to re-visit that patch with a fine tooth comb before
> submitting it. In any case, here it is so far:
> https://github.com/pmj/edk2/commit/58e0510c6da62d5a985b97e9bff84bc53442d3fe
> 
> I am intending to submit more patches to edk2 over time - like this
> one, they'll mostly be based on Reza Jelveh's GSoC project from a few
> years ago. Some of his work on getting OS X/macOS guests working in
> Qemu/OVMF have got upstreamed, most of it has not. I'm hoping I can
> improve the ratio a little.
> 
> I've also written an EFI framebuffer driver for the VMware virtual
> SVGA adapter in Qemu, which again I need to tidy up to conform with
> the coding conventions before submitting. (The only advantage of this
> vs. QXL or virtio-gpu being that there are OSes, including OSX/macOS
> for which there exist drivers for neither QXL nor virtio-gpu.)
> 
> So I guess I may as well get some practice. :-)
> 
> 
> I anticipate submitting the memoisation patch for review on Thursday
> or Friday as I'll be out tomorrow.

Sounds good to me!

Thanks,
Laszlo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]