search for: system_reset

...com32/gpllib/dmi/dmi.c | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/com32/gpllib/dmi/dmi.c b/com32/gpllib/dmi/dmi.c index ef84e1e..5a25b41 100644 --- a/com32/gpllib/dmi/dmi.c +++ b/com32/gpllib/dmi/dmi.c @@ -100,20 +100,20 @@ static const char *dmi_system_reset_boot_option(uint8_t code) return out_of_spec; } -static void dmi_system_reset_count(uint16_t code, char *array) +static void dmi_system_reset_count(uint16_t code, char *array, size_t len) { if (code == 0xFFFF) - strlcpy(array, "Unknown", sizeof array); + strlcpy(array, &quot...

...serial) + LUA_ADD_STR_P(L, system, uuid) + LUA_ADD_STR_P(L, system, wakeup_type) + LUA_ADD_STR_P(L, system, sku_number) + LUA_ADD_STR_P(L, system, family) + LUA_ADD_STR_P(L, system, system_boot_status) + LUA_ADD_STR_P(L, system, configuration_options) + + /* system reset */ + if (system->system_reset.filled) { + lua_pushstring(L, "reset"); + lua_newtable(L); + LUA_ADD_NUM_S(L, system->system_reset, status) + LUA_ADD_NUM_S(L, system->system_reset, watchdog) + LUA_ADD_STR_S(L, system->system_reset, boot_option) + LUA_ADD_STR_S(L, system->system_reset, boot_...

These patches fix a few compiler warnings. Tested on top of commit aee0dc5565711ef5be7c30fb5fc1c5f3f98db09f Jonathan Boeing (6): Use z width specifier when printing size_t variable pxe: fix truncation warning gpllib: fix sizeof(char *) misuse hdt: fix sizeof(char *) misuse hdt: fix sizeof(char *) misuse hdt: fix sizeof(char *) misuse com32/gpllib/dmi/dmi.c | 24 +++---

...e & virtio(virtio_net) >> >> Host freeze at "virsh reset <domain>" or "virt-manager - Force Reset" >> Need kernel.sysrq or power reset. > > I don't believe this is a libvirt issue - the 'virsh reset' command > will issue the 'system_reset' QEMU monitor command. This in turn > does an immediate reset of the guest CPUs/machine. > > Even if QEMU is doing the wrong thing, the kernel should obviously > never freeze/crash in this way - it should be robust against a > malicious QEMU process. > > You should probab...

Hello people, libvirtd (libvirt) 1.0.5.2 virsh 1.0.5.2 virt-manager 0.10.0 Host: Linux localhost 3.9.8-300.fc19.x86_64 #1 SMP Thu Jun 27 19:24:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Guest1: Linux localhost 3.9.8-300.fc19.i686.PAE #1 SMP Thu Jun 27 19:29:30 UTC 2013 i686 (none) Guest2: Linux localhost 3.9.8-300.fc19.x86_64 #1 SMP Thu Jun 27 19:24:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

...nux guest will deflate the balloon (all or some pages) in the following scenarios: a) page migration b) unload virtio-balloon kernel module c) hibernate/suspension d) (DEFLATE_ON_OOM) A Linux guest will touch memory without deflating: a) During a kexec() dump d) On reboots (regular, after kexec(), system_reset) > >> Any change we >> introduce will break backwards compatibility. > > Why does this have to be the case If we suddenly enforce the existing virtio-balloon, we will break legacy guests. Simple example: Guest with inflated virtio-balloon reboots. Touches inflated memory...

...nux guest will deflate the balloon (all or some pages) in the following scenarios: a) page migration b) unload virtio-balloon kernel module c) hibernate/suspension d) (DEFLATE_ON_OOM) A Linux guest will touch memory without deflating: a) During a kexec() dump d) On reboots (regular, after kexec(), system_reset) > >> Any change we >> introduce will break backwards compatibility. > > Why does this have to be the case If we suddenly enforce the existing virtio-balloon, we will break legacy guests. Simple example: Guest with inflated virtio-balloon reboots. Touches inflated memory...

On 04/27/2017 04:31 PM, Stefano Ricci wrote: > Here is the backtrace of the libvirt process just started [Just a side note, you shouldn't top post on technical lists. Gmail sucks at this.] > > https://pastebin.com/R66myzFp Looks like libvirtd is trying to spawn /usr/bin/qemu-system-x86_64 but it takes ages to init. In the debug logs you might see the actual command line that

...uot;}, {"name": "x-blockdev-change"}, {"name": > "transaction"}, {"name": "trace-event-set-state"}, {"name": > "trace-event-get-state"}, {"name": "system_wakeup"}, {"name": > "system_reset"}, {"name": "system_powerdown"}, {"name": "stop"}, > {"name": "set_password"}, {"name": "set_link"}, {"name": "send-key"}, > {"name": "screendump"}, {"name":...

...el: > macvtap/NAT/bridge & virtio(virtio_net) > > Host freeze at "virsh reset <domain>" or "virt-manager - Force Reset" > Need kernel.sysrq or power reset. I don't believe this is a libvirt issue - the 'virsh reset' command will issue the 'system_reset' QEMU monitor command. This in turn does an immediate reset of the guest CPUs/machine. Even if QEMU is doing the wrong thing, the kernel should obviously never freeze/crash in this way - it should be robust against a malicious QEMU process. You should probably send this message to the main QE...

...-blockdev-del"}, {"name": "x-blockdev-change"}, {"name": "transaction"}, {"name": "trace-event-set-state"}, {"name": "trace-event-get-state"}, {"name": "system_wakeup"}, {"name": "system_reset"}, {"name": "system_powerdown"}, {"name": "stop"}, {"name": "set_password"}, {"name": "set_link"}, {"name": "send-key"}, {"name": "screendump"}, {"name": "rtc-...

...39;t it? > b) unload virtio-balloon kernel module > c) hibernate/suspension > d) (DEFLATE_ON_OOM) You need to set a flag in the balloon to allow this, right? > A Linux guest will touch memory without deflating: > a) During a kexec() dump > d) On reboots (regular, after kexec(), system_reset) > > > >> Any change we > >> introduce will break backwards compatibility. > > > > Why does this have to be the case > If we suddenly enforce the existing virtio-balloon, we will break legacy > guests. Can't we do it with a feature flag? > Sim...

...t;name": "x-blockdev-change"}, {"name": >> "transaction"}, {"name": "trace-event-set-state"}, {"name": >> "trace-event-get-state"}, {"name": "system_wakeup"}, {"name": >> "system_reset"}, {"name": "system_powerdown"}, {"name": "stop"}, >> {"name": "set_password"}, {"name": "set_link"}, {"name": "send-key"}, >> {"name": "screendump"}, {"name...

...; } <- {"return": [{"name": "quit"}, {"name": "eject"}, {"name": "change"}, {"name": "screendump"}, {"name": "stop"}, {"name": "cont"}, {"name": "system_reset"}, {"name": "system_powerdown"}, {"name": "device_add"}, {"name": "device_del"}, {"name": "cpu"}, {"name": "memsave"}, {"name": "pmemsave"}, {"name": "mi...

This patch series makes suspend support in qemu alot more useful. Right now the guest can put itself into s3, but qemu will wakeup the guest instantly. With this patch series applied the guest will stay suspended instead and there are a few events which can kick the guest out of suspend state: A monitor command, ps/2 input, serial input, rtc. Not much yet, but it''s a start with the

Hi, this is an idea that is based on Andrea Arcangeli's original idea to host enforce guest access to memory given up using virtio-balloon using userfaultfd in the hypervisor. While looking into the details, I realized that host-enforcing virtio-balloon would result in way too many problems (mainly backwards compatibility) and would also have some conceptual restrictions that I want to avoid.

Hi, this is an idea that is based on Andrea Arcangeli's original idea to host enforce guest access to memory given up using virtio-balloon using userfaultfd in the hypervisor. While looking into the details, I realized that host-enforcing virtio-balloon would result in way too many problems (mainly backwards compatibility) and would also have some conceptual restrictions that I want to avoid.