SeaBIOS July 2012

seabios@seabios.org

37 participants
119 discussions

Re: [SeaBIOS] Plan to add POST memory manager (PMM) support
by Fred . 15 Jul '12

15 Jul '12

Good luck with it! :) Hope to hear back soon how it goes with it, and patches contributed back upstreams. On Sun, Jul 15, 2012 at 6:14 AM, Darmawan Salihun <darmawan.salihun(a)gmail.com> wrote: > Hi Fred, > > Yes, I need it to test something at work. It's not very urgent at the moment. > > Regards, > > Darmawan > > On 7/15/12, Fred . <eldmannen(a)gmail.com> wrote: >> Darmawan, will you be implementing PnP support in SeaBIOS? >> >> On Sat, Jul 14, 2012 at 9:50 PM, Darmawan Salihun >> <darmawan.salihun(a)gmail.com> wrote: >>> On 7/15/12, Kevin O'Connor <kevin(a)koconnor.net> wrote: >>>> On Sun, Jul 15, 2012 at 02:20:42AM +0700, Darmawan Salihun wrote: >>>>> First, I made a mistake, I was actually referring to the PnP support >>>> >>>> On Sat, Jul 14, 2012 at 10:57:00PM +0700, Darmawan Salihun wrote: >>>>> Is there any plan to add this feature in the near future? >>>>> I have a plan to add the feature if it's not there yet, but I want to >>>>> know first whether >>>>> there's already plan for that. >>>> >>>> I have no plans to implement PnP, and I have not heard of any plans >>>> from anyone else. To the best of my knowledge, nothing really uses >>>> the PnP interface anymore. The stubs are in SeaBIOS to make some >>>> option roms (namely gpxe) recognize that the BBS spec is supported. >>>> >>>> Feel free to send patches. >>>> >>>> -Kevin >>>> >>> >>> OK. Thanks for the info. >>> >>> Regards, >>> >>> Darmawan >>> >>> -- >>> -------------------------------------------------------------------- >>> -= Human knowledge belongs to the world =- >>> >>> _______________________________________________ >>> SeaBIOS mailing list >>> SeaBIOS(a)seabios.org >>> http://www.seabios.org/mailman/listinfo/seabios >> > > > -- > -------------------------------------------------------------------- > -= Human knowledge belongs to the world =-

1 0

Re: [SeaBIOS] [Qemu-devel] [QEMU PATCH 2/7] hw/apic.c: rename bit functions to not conflict with bitops.h
by Gleb Natapov 15 Jul '12

15 Jul '12

On Sat, Jul 14, 2012 at 09:09:23AM +0000, Blue Swirl wrote: > On Fri, Jul 13, 2012 at 6:07 PM, Eduardo Habkost <ehabkost(a)redhat.com> wrote: > > On Thu, Jul 12, 2012 at 07:24:35PM +0000, Blue Swirl wrote: > >> On Tue, Jul 10, 2012 at 8:22 PM, Eduardo Habkost <ehabkost(a)redhat.com> wrote: > >> > Signed-off-by: Eduardo Habkost <ehabkost(a)redhat.com> > >> > >> Maybe the bitops functions should be renamed instead, for example > >> prefixed by 'qemu_'. That may be safer if one day the kernel find > >> their way to system headers too. > > > > Well, if there's any risk the kernel functions will conflict with the > > QEMU function names, that would be an additional reason to rename the > > apic.c functions too, so they don't conflict with the kernel functions > > either. > > Yes, that could be the case too. > Than it would be Linux headers problem and will be fixed there. > > > > Personally, I would never sent a patch to rename the bitops.h functions, > > as the current names work perfectly to me. > > > >> > >> > --- > >> > hw/apic.c | 34 +++++++++++++++++----------------- > >> > 1 file changed, 17 insertions(+), 17 deletions(-) > >> > > >> > diff --git a/hw/apic.c b/hw/apic.c > >> > index 60552df..d322fe3 100644 > >> > --- a/hw/apic.c > >> > +++ b/hw/apic.c > >> > @@ -50,7 +50,7 @@ static int ffs_bit(uint32_t value) > >> > return ctz32(value); > >> > } > >> > > >> > -static inline void set_bit(uint32_t *tab, int index) > >> > +static inline void apic_set_bit(uint32_t *tab, int index) > >> > { > >> > int i, mask; > >> > i = index >> 5; > >> > @@ -58,7 +58,7 @@ static inline void set_bit(uint32_t *tab, int index) > >> > tab[i] |= mask; > >> > } > >> > > >> > -static inline void reset_bit(uint32_t *tab, int index) > >> > +static inline void apic_reset_bit(uint32_t *tab, int index) > >> > { > >> > int i, mask; > >> > i = index >> 5; > >> > @@ -66,7 +66,7 @@ static inline void reset_bit(uint32_t *tab, int index) > >> > tab[i] &= ~mask; > >> > } > >> > > >> > -static inline int get_bit(uint32_t *tab, int index) > >> > +static inline int apic_get_bit(uint32_t *tab, int index) > >> > { > >> > int i, mask; > >> > i = index >> 5; > >> > @@ -183,7 +183,7 @@ void apic_deliver_pic_intr(DeviceState *d, int level) > >> > case APIC_DM_FIXED: > >> > if (!(lvt & APIC_LVT_LEVEL_TRIGGER)) > >> > break; > >> > - reset_bit(s->irr, lvt & 0xff); > >> > + apic_reset_bit(s->irr, lvt & 0xff); > >> > /* fall through */ > >> > case APIC_DM_EXTINT: > >> > cpu_reset_interrupt(s->cpu_env, CPU_INTERRUPT_HARD); > >> > @@ -379,13 +379,13 @@ void apic_poll_irq(DeviceState *d) > >> > > >> > static void apic_set_irq(APICCommonState *s, int vector_num, int trigger_mode) > >> > { > >> > - apic_report_irq_delivered(!get_bit(s->irr, vector_num)); > >> > + apic_report_irq_delivered(!apic_get_bit(s->irr, vector_num)); > >> > > >> > - set_bit(s->irr, vector_num); > >> > + apic_set_bit(s->irr, vector_num); > >> > if (trigger_mode) > >> > - set_bit(s->tmr, vector_num); > >> > + apic_set_bit(s->tmr, vector_num); > >> > else > >> > - reset_bit(s->tmr, vector_num); > >> > + apic_reset_bit(s->tmr, vector_num); > >> > if (s->vapic_paddr) { > >> > apic_sync_vapic(s, SYNC_ISR_IRR_TO_VAPIC); > >> > /* > >> > @@ -405,8 +405,8 @@ static void apic_eoi(APICCommonState *s) > >> > isrv = get_highest_priority_int(s->isr); > >> > if (isrv < 0) > >> > return; > >> > - reset_bit(s->isr, isrv); > >> > - if (!(s->spurious_vec & APIC_SV_DIRECTED_IO) && get_bit(s->tmr, isrv)) { > >> > + apic_reset_bit(s->isr, isrv); > >> > + if (!(s->spurious_vec & APIC_SV_DIRECTED_IO) && apic_get_bit(s->tmr, isrv)) { > >> > ioapic_eoi_broadcast(isrv); > >> > } > >> > apic_sync_vapic(s, SYNC_FROM_VAPIC | SYNC_TO_VAPIC); > >> > @@ -445,7 +445,7 @@ static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, > >> > int idx = apic_find_dest(dest); > >> > memset(deliver_bitmask, 0x00, MAX_APIC_WORDS * sizeof(uint32_t)); > >> > if (idx >= 0) > >> > - set_bit(deliver_bitmask, idx); > >> > + apic_set_bit(deliver_bitmask, idx); > >> > } > >> > } else { > >> > /* XXX: cluster mode */ > >> > @@ -455,11 +455,11 @@ static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, > >> > if (apic_iter) { > >> > if (apic_iter->dest_mode == 0xf) { > >> > if (dest & apic_iter->log_dest) > >> > - set_bit(deliver_bitmask, i); > >> > + apic_set_bit(deliver_bitmask, i); > >> > } else if (apic_iter->dest_mode == 0x0) { > >> > if ((dest & 0xf0) == (apic_iter->log_dest & 0xf0) && > >> > (dest & apic_iter->log_dest & 0x0f)) { > >> > - set_bit(deliver_bitmask, i); > >> > + apic_set_bit(deliver_bitmask, i); > >> > } > >> > } > >> > } else { > >> > @@ -502,14 +502,14 @@ static void apic_deliver(DeviceState *d, uint8_t dest, uint8_t dest_mode, > >> > break; > >> > case 1: > >> > memset(deliver_bitmask, 0x00, sizeof(deliver_bitmask)); > >> > - set_bit(deliver_bitmask, s->idx); > >> > + apic_set_bit(deliver_bitmask, s->idx); > >> > break; > >> > case 2: > >> > memset(deliver_bitmask, 0xff, sizeof(deliver_bitmask)); > >> > break; > >> > case 3: > >> > memset(deliver_bitmask, 0xff, sizeof(deliver_bitmask)); > >> > - reset_bit(deliver_bitmask, s->idx); > >> > + apic_reset_bit(deliver_bitmask, s->idx); > >> > break; > >> > } > >> > > >> > @@ -557,8 +557,8 @@ int apic_get_interrupt(DeviceState *d) > >> > apic_sync_vapic(s, SYNC_TO_VAPIC); > >> > return s->spurious_vec & 0xff; > >> > } > >> > - reset_bit(s->irr, intno); > >> > - set_bit(s->isr, intno); > >> > + apic_reset_bit(s->irr, intno); > >> > + apic_set_bit(s->isr, intno); > >> > apic_sync_vapic(s, SYNC_TO_VAPIC); > >> > apic_update_irq(s); > >> > return intno; > >> > -- > >> > 1.7.10.4 > >> > > >> > > >> > > > > -- > > Eduardo -- Gleb.

1 0

Re: [SeaBIOS] Plan to add POST memory manager (PMM) support
by Darmawan Salihun 15 Jul '12

15 Jul '12

Hi Fred, Yes, I need it to test something at work. It's not very urgent at the moment. Regards, Darmawan On 7/15/12, Fred . <eldmannen(a)gmail.com> wrote: > Darmawan, will you be implementing PnP support in SeaBIOS? > > On Sat, Jul 14, 2012 at 9:50 PM, Darmawan Salihun > <darmawan.salihun(a)gmail.com> wrote: >> On 7/15/12, Kevin O'Connor <kevin(a)koconnor.net> wrote: >>> On Sun, Jul 15, 2012 at 02:20:42AM +0700, Darmawan Salihun wrote: >>>> First, I made a mistake, I was actually referring to the PnP support >>> >>> On Sat, Jul 14, 2012 at 10:57:00PM +0700, Darmawan Salihun wrote: >>>> Is there any plan to add this feature in the near future? >>>> I have a plan to add the feature if it's not there yet, but I want to >>>> know first whether >>>> there's already plan for that. >>> >>> I have no plans to implement PnP, and I have not heard of any plans >>> from anyone else. To the best of my knowledge, nothing really uses >>> the PnP interface anymore. The stubs are in SeaBIOS to make some >>> option roms (namely gpxe) recognize that the BBS spec is supported. >>> >>> Feel free to send patches. >>> >>> -Kevin >>> >> >> OK. Thanks for the info. >> >> Regards, >> >> Darmawan >> >> -- >> -------------------------------------------------------------------- >> -= Human knowledge belongs to the world =- >> >> _______________________________________________ >> SeaBIOS mailing list >> SeaBIOS(a)seabios.org >> http://www.seabios.org/mailman/listinfo/seabios > -- -------------------------------------------------------------------- -= Human knowledge belongs to the world =-

1 0

Re: [SeaBIOS] Plan to add POST memory manager (PMM) support
by Fred . 15 Jul '12

15 Jul '12

Darmawan, will you be implementing PnP support in SeaBIOS? On Sat, Jul 14, 2012 at 9:50 PM, Darmawan Salihun <darmawan.salihun(a)gmail.com> wrote: > On 7/15/12, Kevin O'Connor <kevin(a)koconnor.net> wrote: >> On Sun, Jul 15, 2012 at 02:20:42AM +0700, Darmawan Salihun wrote: >>> First, I made a mistake, I was actually referring to the PnP support >> >> On Sat, Jul 14, 2012 at 10:57:00PM +0700, Darmawan Salihun wrote: >>> Is there any plan to add this feature in the near future? >>> I have a plan to add the feature if it's not there yet, but I want to >>> know first whether >>> there's already plan for that. >> >> I have no plans to implement PnP, and I have not heard of any plans >> from anyone else. To the best of my knowledge, nothing really uses >> the PnP interface anymore. The stubs are in SeaBIOS to make some >> option roms (namely gpxe) recognize that the BBS spec is supported. >> >> Feel free to send patches. >> >> -Kevin >> > > OK. Thanks for the info. > > Regards, > > Darmawan > > -- > -------------------------------------------------------------------- > -= Human knowledge belongs to the world =- > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios

1 0

Re: [SeaBIOS] Plan to add POST memory manager (PMM) support
by Kevin O'Connor 14 Jul '12

14 Jul '12

On Sun, Jul 15, 2012 at 02:20:42AM +0700, Darmawan Salihun wrote: > First, I made a mistake, I was actually referring to the PnP support On Sat, Jul 14, 2012 at 10:57:00PM +0700, Darmawan Salihun wrote: > Is there any plan to add this feature in the near future? > I have a plan to add the feature if it's not there yet, but I want to > know first whether > there's already plan for that. I have no plans to implement PnP, and I have not heard of any plans from anyone else. To the best of my knowledge, nothing really uses the PnP interface anymore. The stubs are in SeaBIOS to make some option roms (namely gpxe) recognize that the BBS spec is supported. Feel free to send patches. -Kevin

2 1

Re: [SeaBIOS] Plan to add POST memory manager (PMM) support
by Kevin O'Connor 14 Jul '12

14 Jul '12

On Sat, Jul 14, 2012 at 10:57:00PM +0700, Darmawan Salihun wrote: > Hi guys, > > Last time I check there's no support for POST Memory Manager (PMM) in > SeaBIOS yet. SeaBIOS has had PMM support for some time. See src/pmm.c. -Kevin

2 1

Plan to add POST memory manager (PMM) support
by Darmawan Salihun 14 Jul '12

14 Jul '12

Hi guys, Last time I check there's no support for POST Memory Manager (PMM) in SeaBIOS yet. Is there any plan to add this feature in the near future? I have a plan to add the feature if it's not there yet, but I want to know first whether there's already plan for that. Thanks, Darmawan -- -------------------------------------------------------------------- -= Human knowledge belongs to the world =-

1 0

Re: [SeaBIOS] [Qemu-devel] [QEMU RFC PATCH 6/7] i386: topology & APIC ID utility functions
by Eduardo Habkost 14 Jul '12

14 Jul '12

On Thu, Jul 12, 2012 at 07:37:26PM +0000, Blue Swirl wrote: > On Tue, Jul 10, 2012 at 8:22 PM, Eduardo Habkost <ehabkost(a)redhat.com> wrote: [...] > > +#ifndef __QEMU_X86_TOPOLOGY_H__ > > +#define __QEMU_X86_TOPOLOGY_H__ > > Please remove the leading and trailing underscores. The name should > match the path, so it should be TARGET_I386_TOPOLOGY_H. Done. Will be fixed in the next version. > > > +/* Bit offset of the Core_ID field > > + */ > > +static inline unsigned apicid_core_offset(unsigned nr_cores, > > + unsigned nr_threads) > > +{ > > + return apicid_smt_width(nr_cores, nr_threads); > > The indentation seems to be off, please use checkpatch.pl to avoid these issues. Fixed for the next version. (BTW, checkpatch.pl didn't detect any issues on this patch) > > > +} > > + > > +/* Bit offset of the Pkg_ID (socket ID) field > > + */ > > +static inline unsigned apicid_pkg_offset(unsigned nr_cores, unsigned nr_threads) > > +{ > > + return apicid_core_offset(nr_cores, nr_threads) + \ > > + apicid_core_width(nr_cores, nr_threads); > > +} > > + > > +/* Make APIC ID for the CPU based on Pkg_ID, Core_ID, SMT_ID > > + * > > + * The caller must make sure core_id < nr_cores and smt_id < nr_threads. > > + */ > > +static inline uint8_t __make_apicid(unsigned nr_cores, unsigned nr_threads, > > Again, remove leading underscores. Fixed for the next version. > [...] > > diff --git a/tests/Makefile b/tests/Makefile > > index b605e14..89bd890 100644 > > --- a/tests/Makefile > > +++ b/tests/Makefile > > @@ -15,6 +15,7 @@ check-unit-y += tests/test-string-output-visitor$(EXESUF) > > check-unit-y += tests/test-coroutine$(EXESUF) > > check-unit-y += tests/test-visitor-serialization$(EXESUF) > > check-unit-y += tests/test-iov$(EXESUF) > > +check-unit-y += tests/test-x86-cpuid$(EXESUF) > > This probably tries to build the cpuid test also for non-x86 targets > and break them all. I don't think there's any concept of "targets" for the check-unit tests. I had to do the following, to be able to make a test that uses the target-i386 code: > > +tests/test-x86-cpuid.o: QEMU_INCLUDES += -Itarget-i386 Any suggestions to avoid this hack would be welcome. > [...] > > + g_assert_cmpuint(topo_make_apicid(6, 3, 0), ==, 0); > > + g_assert_cmpuint(topo_make_apicid(6, 3, 1), ==, 1); > > + g_assert_cmpuint(topo_make_apicid(6, 3, 2), ==, 2); > > + > > + g_assert_cmpuint(topo_make_apicid(6, 3, 1*3 + 0), ==, (1<<2) | 0); > > Spaces are needed around operators. > Do you honestly believe that this: g_assert_cmpuint(topo_make_apicid(6, 3, 5 * 3 + 0), ==, (5 << 2) | 0); g_assert_cmpuint(topo_make_apicid(6, 3, 5 * 3 + 1), ==, (5 << 2) | 1); g_assert_cmpuint(topo_make_apicid(6, 3, 5 * 3 + 2), ==, (5 << 2) | 2); is more readable than this: g_assert_cmpuint(topo_make_apicid(6, 3, 5*3 + 0), ==, (5<<2) | 0); g_assert_cmpuint(topo_make_apicid(6, 3, 5*3 + 1), ==, (5<<2) | 1); g_assert_cmpuint(topo_make_apicid(6, 3, 5*3 + 2), ==, (5<<2) | 2); ? (I don't). > > + g_assert_cmpuint(topo_make_apicid(6, 3, 1*3 + 1), ==, (1<<2) | 1); > > + g_assert_cmpuint(topo_make_apicid(6, 3, 1*3 + 2), ==, (1<<2) | 2); > > + > > + g_assert_cmpuint(topo_make_apicid(6, 3, 2*3 + 0), ==, (2<<2) | 0); > > + g_assert_cmpuint(topo_make_apicid(6, 3, 2*3 + 1), ==, (2<<2) | 1); > > + g_assert_cmpuint(topo_make_apicid(6, 3, 2*3 + 2), ==, (2<<2) | 2); > > + > > + g_assert_cmpuint(topo_make_apicid(6, 3, 5*3 + 0), ==, (5<<2) | 0); > > + g_assert_cmpuint(topo_make_apicid(6, 3, 5*3 + 1), ==, (5<<2) | 1); > > + g_assert_cmpuint(topo_make_apicid(6, 3, 5*3 + 2), ==, (5<<2) | 2); > > + > > + g_assert_cmpuint(topo_make_apicid(6, 3, 1*6*3 + 0*3 + 0), ==, (1<<5)); > > + g_assert_cmpuint(topo_make_apicid(6, 3, 1*6*3 + 1*3 + 1), ==, > > + (1<<5) | (1<<2) | 1); > > + > > + g_assert_cmpuint(topo_make_apicid(6, 3, 3*6*3 + 5*3 + 2), ==, > > + (3<<5) | (5<<2) | 2); > > + > > + > > + /* Check the APIC ID -> {pkg,core,thread} ID functions */ > > + g_assert_cmpuint(apicid_pkg_id(6, 3, (3<<5) | (5<<2) | 2), ==, 3); > > + g_assert_cmpuint(apicid_core_id(6, 3, (3<<5) | (5<<2) | 2), ==, 5); > > + g_assert_cmpuint(apicid_smt_id(6, 3, (3<<5) | (5<<2) | 2), ==, 2); > > +} > > + > > +int main(int argc, char **argv) > > +{ > > + g_test_init(&argc, &argv, NULL); > > + > > + g_test_add_func("/cpuid/topology/basic", test_topo_bits); > > + > > + g_test_run(); > > + > > + return 0; > > +} > > -- > > 1.7.10.4 > > > > > -- Eduardo

2 1

Re: [SeaBIOS] [Qemu-devel] [QEMU PATCH 2/7] hw/apic.c: rename bit functions to not conflict with bitops.h
by Eduardo Habkost 14 Jul '12

14 Jul '12

On Thu, Jul 12, 2012 at 07:24:35PM +0000, Blue Swirl wrote: > On Tue, Jul 10, 2012 at 8:22 PM, Eduardo Habkost <ehabkost(a)redhat.com> wrote: > > Signed-off-by: Eduardo Habkost <ehabkost(a)redhat.com> > > Maybe the bitops functions should be renamed instead, for example > prefixed by 'qemu_'. That may be safer if one day the kernel find > their way to system headers too. Well, if there's any risk the kernel functions will conflict with the QEMU function names, that would be an additional reason to rename the apic.c functions too, so they don't conflict with the kernel functions either. Personally, I would never sent a patch to rename the bitops.h functions, as the current names work perfectly to me. > > > --- > > hw/apic.c | 34 +++++++++++++++++----------------- > > 1 file changed, 17 insertions(+), 17 deletions(-) > > > > diff --git a/hw/apic.c b/hw/apic.c > > index 60552df..d322fe3 100644 > > --- a/hw/apic.c > > +++ b/hw/apic.c > > @@ -50,7 +50,7 @@ static int ffs_bit(uint32_t value) > > return ctz32(value); > > } > > > > -static inline void set_bit(uint32_t *tab, int index) > > +static inline void apic_set_bit(uint32_t *tab, int index) > > { > > int i, mask; > > i = index >> 5; > > @@ -58,7 +58,7 @@ static inline void set_bit(uint32_t *tab, int index) > > tab[i] |= mask; > > } > > > > -static inline void reset_bit(uint32_t *tab, int index) > > +static inline void apic_reset_bit(uint32_t *tab, int index) > > { > > int i, mask; > > i = index >> 5; > > @@ -66,7 +66,7 @@ static inline void reset_bit(uint32_t *tab, int index) > > tab[i] &= ~mask; > > } > > > > -static inline int get_bit(uint32_t *tab, int index) > > +static inline int apic_get_bit(uint32_t *tab, int index) > > { > > int i, mask; > > i = index >> 5; > > @@ -183,7 +183,7 @@ void apic_deliver_pic_intr(DeviceState *d, int level) > > case APIC_DM_FIXED: > > if (!(lvt & APIC_LVT_LEVEL_TRIGGER)) > > break; > > - reset_bit(s->irr, lvt & 0xff); > > + apic_reset_bit(s->irr, lvt & 0xff); > > /* fall through */ > > case APIC_DM_EXTINT: > > cpu_reset_interrupt(s->cpu_env, CPU_INTERRUPT_HARD); > > @@ -379,13 +379,13 @@ void apic_poll_irq(DeviceState *d) > > > > static void apic_set_irq(APICCommonState *s, int vector_num, int trigger_mode) > > { > > - apic_report_irq_delivered(!get_bit(s->irr, vector_num)); > > + apic_report_irq_delivered(!apic_get_bit(s->irr, vector_num)); > > > > - set_bit(s->irr, vector_num); > > + apic_set_bit(s->irr, vector_num); > > if (trigger_mode) > > - set_bit(s->tmr, vector_num); > > + apic_set_bit(s->tmr, vector_num); > > else > > - reset_bit(s->tmr, vector_num); > > + apic_reset_bit(s->tmr, vector_num); > > if (s->vapic_paddr) { > > apic_sync_vapic(s, SYNC_ISR_IRR_TO_VAPIC); > > /* > > @@ -405,8 +405,8 @@ static void apic_eoi(APICCommonState *s) > > isrv = get_highest_priority_int(s->isr); > > if (isrv < 0) > > return; > > - reset_bit(s->isr, isrv); > > - if (!(s->spurious_vec & APIC_SV_DIRECTED_IO) && get_bit(s->tmr, isrv)) { > > + apic_reset_bit(s->isr, isrv); > > + if (!(s->spurious_vec & APIC_SV_DIRECTED_IO) && apic_get_bit(s->tmr, isrv)) { > > ioapic_eoi_broadcast(isrv); > > } > > apic_sync_vapic(s, SYNC_FROM_VAPIC | SYNC_TO_VAPIC); > > @@ -445,7 +445,7 @@ static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, > > int idx = apic_find_dest(dest); > > memset(deliver_bitmask, 0x00, MAX_APIC_WORDS * sizeof(uint32_t)); > > if (idx >= 0) > > - set_bit(deliver_bitmask, idx); > > + apic_set_bit(deliver_bitmask, idx); > > } > > } else { > > /* XXX: cluster mode */ > > @@ -455,11 +455,11 @@ static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, > > if (apic_iter) { > > if (apic_iter->dest_mode == 0xf) { > > if (dest & apic_iter->log_dest) > > - set_bit(deliver_bitmask, i); > > + apic_set_bit(deliver_bitmask, i); > > } else if (apic_iter->dest_mode == 0x0) { > > if ((dest & 0xf0) == (apic_iter->log_dest & 0xf0) && > > (dest & apic_iter->log_dest & 0x0f)) { > > - set_bit(deliver_bitmask, i); > > + apic_set_bit(deliver_bitmask, i); > > } > > } > > } else { > > @@ -502,14 +502,14 @@ static void apic_deliver(DeviceState *d, uint8_t dest, uint8_t dest_mode, > > break; > > case 1: > > memset(deliver_bitmask, 0x00, sizeof(deliver_bitmask)); > > - set_bit(deliver_bitmask, s->idx); > > + apic_set_bit(deliver_bitmask, s->idx); > > break; > > case 2: > > memset(deliver_bitmask, 0xff, sizeof(deliver_bitmask)); > > break; > > case 3: > > memset(deliver_bitmask, 0xff, sizeof(deliver_bitmask)); > > - reset_bit(deliver_bitmask, s->idx); > > + apic_reset_bit(deliver_bitmask, s->idx); > > break; > > } > > > > @@ -557,8 +557,8 @@ int apic_get_interrupt(DeviceState *d) > > apic_sync_vapic(s, SYNC_TO_VAPIC); > > return s->spurious_vec & 0xff; > > } > > - reset_bit(s->irr, intno); > > - set_bit(s->isr, intno); > > + apic_reset_bit(s->irr, intno); > > + apic_set_bit(s->isr, intno); > > apic_sync_vapic(s, SYNC_TO_VAPIC); > > apic_update_irq(s); > > return intno; > > -- > > 1.7.10.4 > > > > > -- Eduardo

2 1

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v2 00/21] ACPI memory hotplug
by Blue Swirl 14 Jul '12

14 Jul '12

On Fri, Jul 13, 2012 at 5:49 PM, Vasilis Liaskovitis <vasilis.liaskovitis(a)profitbricks.com> wrote: > On Thu, Jul 12, 2012 at 08:04:56PM +0000, Blue Swirl wrote: >> On Wed, Jul 11, 2012 at 10:31 AM, Vasilis Liaskovitis >> <vasilis.liaskovitis(a)profitbricks.com> wrote: >> > This is v2 of the ACPI memory hotplug prototype for x86_64 target. >> >> I think the concept of DIMMs (what about SIMMs? SODIMMs? I liked >> memslot) would be useful for most targets, but hotplugging may be >> limited to x86 only. It would be nice to keep these two separate or as >> loosely coupled as possible. > > agreed. > what specific usecases besides hotplugging are you thinking about? Most real boards have some kind of RAM module slots. Now this is implemented with -m option, but a generic memory slot model would be more accurate. Also the memory layout needs to be communicated to BIOS somehow unless we want to spend cycles for BIOS memory probes. The NUMA fw_cfg memory description should be usable for most cases even for embedded UP machines. > Also are there non-acpi hotplug platforms? Some enterprise-class Sparc and PPC machines support memory hotplug. > > I am trying to keep generic dimm manipulation functions (e.g. population / > depopulation and searching) in hw/dimm[.ch]. Currently the x86-acpi_piix4 "backend" > registers a callback for hot-add / hot-remove. In theory other hotplug backends > can hook in. > > btw I don't mind using "-memslot" (I think someone during v1 mentioned -dimm), we just > need some consensus on the naming. > >> >> > >> > Changes v1->v2 >> > >> > - memory map is automatically calculated for hotplug dimms. Dimms are added from >> > top-of-memory skipping the pci hole at [PCI_HOLE_START, 4G). >> > - Renamed from "-memslot" to "-dimm". Commands changed to "dimm_add", "dimm_del". >> > - Seabios ejection array reduced to a byte. Use extraction macros for dimm ssdt. >> > - additional SRAT paravirt info does not break previous SRAT fw_cfg layout. >> > - Documentation of new acpi_piix4 registers and paravirt data. >> > - add ACPI _OST support for _OST enabled guests. This allows qemu to receive >> > notification for success / failure of memory hot-add and hot-remove operations. >> > Guest needs to support _OST (https://lkml.org/lkml/2012/6/25/321) >> > - add monitor info command to report total guest memory (initial + hot-added) >> > - add command line options and monitor commands for batch dimm creation/population >> > >> > Overview: >> > >> > Dimm devices are modeled with a new qemu command line >> > >> > "-dimm id=name,size=sz,node=pxm,populated=on|off" >> > >> > As already mentioned, the starting physical address for all dimms is calculated >> > automatically from top of memory, skipping the pci hole at [PCI_HOLE_START, 4G). >> > Node is defining numa proximity for this dimm. When not defined it defaults >> > to zero. >> > "-dimm id=dimm0,size=512M,node=0,populated=off" >> > will define a 512M memory slot belonging to numa node 0. >> > >> > Dimms are added or removed with a new hmp command "dimm_add/dimm_del": >> > Hot-add syntax: "dimm_add id" >> > Hot-remove syntax: "dimm_del id" >> > >> > Issues: >> > >> > - Live migration works as long as populated field is changed to "on" for >> > hotplugged dimms at the destination qemu command line (patch 12/21 lifts >> > this requirement). The DimmState structure does not yet define a >> > VMStateDescription, but i assume this is the preferred way to pass state >> > for migration. >> > >> > - Dimms are abstracted as qdevices attached to the main system bus. However, >> > memory hotplugging has its own side channel ignoring main_system_bus's hotplug >> > incapability. A cleaner integration is still needed, probably attaching memory >> > devices as children-links of an acpi-capable device (in the pc case acpi_piix4) >> > instead of the system bus (TBD). Then device_add/device_del instead of new >> > commands can hopefully be used. >> > >> > Comments/review welcome. >> > >> > series is based on uq/master for qemu-kvm, and master for seabios. Can be found >> > also at: >> > http://github.com/vliaskov/qemu-kvm/commits/memhp-v2 >> > http://github.com/vliaskov/seabios/commits/memhp-v2 >> > >> > Vasilis Liaskovitis (14): >> > dimm: Implement memory device abstraction >> > acpi_piix4: Implement memory device hotplug registers >> > pc: calculate dimm physical addresses and adjust memory map >> > pc: Add dimm paravirt SRAT info >> > Implement "-dimm" command line option >> > Implement dimm_add and dimm_del commands for hmp and qmp >> > fix live-migration when "populated=on" is missing >> > Implement memory hotplug notification lists >> > acpi_piix4: _OST dimm support >> > acpi_piix4: Update dimm state on VM reboot >> > acpi_piix4: Update dimm bitmap state on hot-remove fail >> > Implement "info memtotal" and "query-memtotal" >> > Implement -dimms, -dimmspop command line options >> > Implement mem_increase, mem_decrease hmp/qmp commands >> > >> > arch_init.c | 23 ++- >> > docs/specs/acpi_hotplug.txt | 46 +++++ >> > docs/specs/fwcfg.txt | 28 +++ >> > hmp-commands.hx | 67 +++++++ >> > hmp.c | 24 +++ >> > hmp.h | 2 + >> > hw/Makefile.objs | 2 +- >> > hw/acpi_piix4.c | 131 ++++++++++++- >> > hw/dimm.c | 449 +++++++++++++++++++++++++++++++++++++++++++ >> > hw/dimm.h | 72 +++++++ >> > hw/pc.c | 94 +++++++++- >> > hw/pc.h | 6 + >> > hw/pc_piix.c | 18 ++- >> > monitor.c | 35 ++++ >> > monitor.h | 5 + >> > qapi-schema.json | 38 ++++ >> > qemu-config.c | 70 +++++++ >> > qemu-options.hx | 15 ++ >> > qmp-commands.hx | 137 +++++++++++++ >> > sysemu.h | 1 + >> > vl.c | 122 ++++++++++++- >> > 21 files changed, 1368 insertions(+), 17 deletions(-) >> > create mode 100644 docs/specs/acpi_hotplug.txt >> > create mode 100644 docs/specs/fwcfg.txt >> > create mode 100644 hw/dimm.c >> > create mode 100644 hw/dimm.h >> > >> > Vasilis Liaskovitis (7): >> > Add ACPI_EXTRACT_DEVICE* macros >> > Add SSDT memory device support >> > acpi-dsdt: Implement functions for memory hotplug. >> > acpi: generate hotplug memory devices. >> > pciinit: Fix pcimem_start value >> > acpi_dsdt: Support _OST dimm method >> > acpi_dsdt: Revert internal dimm state on _OST failure >> > >> > Makefile | 2 +- >> > src/acpi-dsdt.dsl | 120 ++++++++++++++++++++++++++++++++++++- >> > src/acpi.c | 158 +++++++++++++++++++++++++++++++++++++++++++++++-- >> > src/pciinit.c | 2 +- >> > src/ssdt-mem.dsl | 69 +++++++++++++++++++++ >> > tools/acpi_extract.py | 28 +++++++++ >> > 6 files changed, 369 insertions(+), 10 deletions(-) >> > create mode 100644 src/ssdt-mem.dsl >> >

1 0

← Newer
1
...
4
5
6
7
8
9
10
11
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS July 2012